Questions & Answers

A CTO owns the technology decisions that are expensive to reverse. Not the day to day code, and not the sprint board: the choices that set the cost of everything you build for the next two or three years.

In practice that is four things. Deciding the architecture and the platform. Deciding what the engineering team should look like and who to hire. Deciding what to build in-house and what to buy. And translating between the technical reality and the commercial one for the CEO, the board and investors.

A good CTO spends more time saying no than yes. Most technical failures at small companies are not bad code. They are the right solution applied to a problem the company does not have yet.

The CPO owns what gets built and why. The CTO owns how it gets built and whether it will hold.

The CPO answers to the market: which customers, which problem, which features, in what order. The CTO answers to reality: can this architecture carry that roadmap, what will it cost to run, what breaks first at ten times the load, how long until the team can ship it safely.

The two roles are in productive tension by design. When they collapse into one person, one of the two questions stops getting asked, and it is almost always the second one.

A CPTO is a single executive holding both product and technology. It is common below roughly thirty people, where there is not enough of either job to justify two executives.

It works while the company is still finding product-market fit and speed matters more than balance. It stops working at the point where the roadmap starts writing cheques the architecture cannot cash, because the person who would push back is the same person who made the promise.

The usual failure is not incompetence. It is that a CPTO under pressure defaults to whichever half of the job the CEO asks about most, and the other half quietly accumulates debt.

They are three different time horizons.

• CTO: two to three years out. Architecture, technology strategy, build versus buy, board-facing technical credibility.
• VP Engineering: two to three quarters out. Delivery, process, the hiring plan, whether the organisation can actually execute the roadmap.
• Engineering Manager: two to three sprints out. A team of five to eight people, their output, their growth, their unblocking.

An Enterprise Architect designs how systems fit together across an organisation. It is a modelling and standards role with real authority in large companies that have many systems and long procurement cycles. Below roughly two hundred engineers it usually has nothing to bite on.

A Tech Lead is a senior engineer who owns the technical direction of one team and still writes code. It is the most useful title on this list for a company under thirty people.

A CTO sits above both and is accountable to the business rather than to the systems. The distinguishing test is simple: if the role's output is a diagram, it is architecture. If the output is a decision with a budget attached, it is the CTO.

If your hardest open question is “how do we build this”, you need a strong lead developer. If it is “should we build this at all, and what does it commit us to”, you need CTO judgement.

Headcount alone does not answer this. Consider the complexity of the platform, the number of teams to coordinate and the decisions the business needs technology leadership to own.

For occasional decision support, an Advisor subscription may fit. For an operational leadership mandate, consider a Fractional CTO. If the need is implementation capacity, TRENDev can scope a delivery mission alongside your lead developer. A free consultation can help define which gap you actually need to fill.

Start with the mandate: what needs to be owned, what authority is required and how much continuity the organisation needs.

A full-time CTO makes sense when leading technology is a sustained executive responsibility across product, people, operations and the board. A Fractional CTO can fit a defined transition, transformation or leadership gap, provided the agreed capacity and authority match the work. It is not a substitute for a full-time role that genuinely needs filling.

There are two different part-time answers. If you need someone to lead a transformation, a governance model or a team through a transition, that is a Fractional CTO: operational leadership with explicitly scoped authority and follow-through. If you need decision support without transferring operational ownership, that is advisory: CTO Advisor or CTO Advisor+.

Choose on the basis of ownership and organisational need, not only hours or price. Compare advisory and Fractional CTO engagements.

These are the boundaries of the subscriptions, not of what TRENDev does. Operational leadership is a Fractional CTO engagement, and implementation can be agreed as a separate, tailored delivery mission: see Can you deliver a project for us?

Being explicit about this early prevents most disappointment later. CTO Advisor and CTO Advisor+ are advisory subscriptions, and they do not include:

• Operational ownership of your systems, teams or delivery
• On-call duty or incident response
• Routine coding or hands-on implementation
• Sprint or project management
• Routine team management
• Unlimited code or document review

Two things happen on a repeating cycle: scheduled strategic sessions, and substantive advice between them.

On CTO Advisor that is typically two strategic sessions a month plus async advice in between. On CTO Advisor+ it is weekly or biweekly sessions, priority async, and a structured Quarterly Technology Review.

Sessions are working sessions, not status updates. You bring the decision that is blocking you, we work it through, and you leave with a position you can act on. Between sessions you send the things that come up: an architecture proposal to review, a hiring shortlist, a vendor quote that smells wrong, a roadmap you want stress-tested.

A Fractional CTO engagement runs differently: its cadence, presence and authority are scoped with you, because the role is to lead and follow through, not only to advise.

Not under the Advisor subscriptions. Routine coding and hands-on implementation are outside their scope: they are advice, analysis and decision support. That is a boundary of the subscription, not of the firm.

Reading code is different from writing it. Reviewing an architecture, reading a critical module to form a view on a risk, or evaluating a technical proposal are all inside scope.

Implementation is something TRENDev does, as separately agreed work: hands-on execution within a Fractional CTO engagement when explicitly scoped, or a tailored delivery mission combining technical leadership and trusted delivery partners. You can start there directly, without an advisory subscription.

When advice could lead to delivery, the safeguards are plain: recommendations rest on evidence and include credible alternatives, any proposed delivery relationship is disclosed, delivery is a separate scope and price, and you remain free to execute internally or choose another provider.

Yes. Advisory is one way to work with TRENDev, not the limit of it. A defined piece of work, designed and implemented, is a tailored delivery engagement, and you do not need to buy advisory first.

TRENDev combines senior technical leadership with trusted delivery partners, assembled around the agreed work. Technical direction, delivery coordination and partner responsibilities are defined for each mission. You know who is involved and how the work will be governed before it starts.

Scope, roles, capacity, fees and acceptance criteria are agreed before the work starts, and the work is planned around your existing team and suppliers. It is not a subscription tier and is never bought through checkout: discuss a delivery project.

The relationship depends on the mandate. In advisory, we provide a senior outside view without taking over operational ownership. In a Fractional CTO or delivery mission, leadership authority, delivery responsibilities and interfaces with your existing team are agreed explicitly.

The failure mode to avoid is an outside advisor who undermines the person actually shipping your product. In practice that means your lead developer is in the room for architecture discussions, disagreements get resolved on the technical merits in front of you, and recommendations are things your team can carry rather than things done to them.

With an outside agency the value is often sharper, because you gain a senior outside view of what you are being told, grounded in evidence. If TRENDev could itself be a candidate for the work under review, we say so up front.

Sometimes. Three situations come up repeatedly.

• A second opinion on a decision that is hard to reverse. A platform migration, a rewrite, a major vendor commitment. An outside, evidence-based read costs a fraction of the decision.
• A CTO who has not yet done the next stage. Someone excellent at ten engineers may not have taken an organisation to fifty. Advisory support for them is cheaper and kinder than replacing them.
• Board or investor due diligence. An outside technical view carries weight that an internal one cannot.

You own what you pay for. Confidentiality obligations are set out in the Terms of Service and run for five years.

One practical rule matters more than the paperwork: do not send credentials, access tokens, secrets or production personal data by email. If something sensitive is central to a discussion, we agree a secure channel first.

If your situation needs a specific NDA rather than the standard terms, raise it at the consultation.

The Advisor subscriptions are remote by default. Sessions are video calls and async advice is written, and that is what keeps the arrangement efficient enough to be worth a few hours a month.

On-site presence is a Fractional CTO matter, where cadence and location are part of the scoped engagement rather than a fixed package.

Base is Serris, France, so on-site in the Paris region is straightforward when an engagement calls for it.

Ask yourself three questions after the first two months.

• Are decisions being made faster, and are they staying made?
• Has anything expensive been avoided that would otherwise have gone ahead?
• Does your engineering team have a clearer picture of what matters this quarter?

Docker packages an application together with everything it needs to run, so it behaves the same on a laptop, in a test environment and in production.

The problem it solves is old and boring: software that works on one machine and fails on another because of a different library version, a different operating system, a different configuration. Containers make that whole class of problem mostly go away.

When it is the right call: almost always, at almost any size. The cost is low and the payoff starts immediately.

When it is not: rarely, and usually only where a specialist runtime makes containers awkward. Docker is not the decision worth agonising over. Kubernetes is.

Kubernetes runs containers across many machines and keeps them running: restarting what dies, scaling what is loaded, and rolling out new versions without downtime.

It is genuinely powerful, and it is genuinely a distributed system in its own right. That second part is what teams underestimate. Running Kubernetes means someone now operates two systems: your product, and the platform underneath it.

Usually not yet, and this is the single most common expensive mistake in small-company infrastructure.

When it earns its place: many services, real scaling demands, multiple teams deploying independently, or a portability requirement you can actually name. Roughly, when you have enough engineers that a platform team is a sensible thing to have.

When it is a costly mistake: a small team running one or two services. You will spend more engineering time operating the cluster than the cluster ever saves you, and you will have introduced an entire category of failure that your managed platform was handling for free.

The uncomfortable version: teams often adopt Kubernetes because it is what the engineers want on their CV, and the business pays for it in delivery speed for two years. Working out which case you are in is a good use of a first session.

Start with a monolith. Nearly always.

Microservices solve an organisational problem, not a technical one: they let many teams deploy without coordinating with each other. If you have one team, you do not have that problem, and you have paid for network calls, distributed transactions and a debugging story that is dramatically harder.

When to split: when teams are genuinely blocking each other on deploys, when parts of the system have wildly different scaling profiles, or when one component sits behind a compliance boundary the rest does not.

The good middle path is a well-structured monolith with clean internal boundaries, so the split stays available later, at the point where you actually know where the seams are.

In roughly this order of frequency:

• Nothing was ever turned off. Test environments, old instances, orphaned volumes and snapshots.
• Over-provisioning bought as insurance. Instances sized for a load that never arrived, and never resized afterwards.
• Data transfer. Cross-region and cross-availability-zone traffic, which is invisible in architecture diagrams and very visible on the bill.
• Managed services chosen without a cost model. Convenient at prototype scale, punishing at production scale.
• No cost ownership. The bill belongs to finance, the spending decisions belong to engineering, and nobody holds both.

Technical debt is the gap between how your system is built and how it would be built if you were designing it for what you now know. Some of it was a deliberate trade to ship faster. Some of it accumulated because nobody had time.

The distinction that matters is not old code versus new code. It is whether the debt sits on the path of what you are about to build. Debt in a stable, rarely touched part of the system costs you nothing and should generally be left alone.

Worth paying down: when it is slowing down the roadmap you have already committed to, when it is a live security or reliability risk, or when it is blocking hiring because nobody wants to work in it.

Not worth paying down: because it is untidy. A rewrite justified on aesthetics is the most expensive thing a small engineering team can do to itself.

“AI readiness” mostly comes down to three unglamorous things.

• Do you have the data, and can you lawfully use it? Access, quality and provenance, including whether your own terms and privacy notices actually permit the use you have in mind.
• Is there a real decision or task to automate? Ideally one where being right eighty percent of the time is already valuable, because that is broadly what these systems deliver.
• Can you tell whether it is working? An evaluation you trust, before it ships. Not a demo that impressed the room.

Proportionate, and mostly boring.

At almost any stage the highest-value items are the same: no long-lived credentials in code or CI, multi-factor authentication everywhere, least-privilege access, dependency patching that actually happens, backups that have been restored at least once, and a written answer to “what do we do in the first hour of a breach”.

That list is cheap and prevents most of what actually happens to small companies.

The expensive items, penetration tests, SOC 2, ISO 27001, are usually driven by a customer or an investor rather than by risk. When they are, treat them as a sales cost and time them to the deal.

When you need multiple parties who do not trust each other to agree on a shared record, and there is no acceptable neutral operator to hold it.

That is a narrow condition and it is worth checking honestly, because a database with good audit logging is faster, cheaper and easier to hire for in every case where it applies.

Where it genuinely does apply, the engineering demands are unforgiving. Deployed contracts are hard to change, mistakes are usually irreversible, and the security bar sits closer to aerospace than to web development.

TRENDev builds in this space and will still tell you when your problem is a database problem.

Once per quarter, a structured review of your architecture, roadmap, delivery and technical risks, concluded with prioritised written recommendations for the next quarter.

It is included in CTO Advisor+, and it is delivered within your included monthly capacity rather than in addition to it.

The point of it is cadence. Advisory conversations naturally follow whatever is urgent that week. The quarterly review is the moment where someone steps back and asks whether the direction is still right.

• CTO Advisor, €1,500 per month excluding applicable taxes. Up to 4 hours a month of advisory capacity, typically two strategic sessions, async advice between them. For founders who own execution themselves and want senior judgement reviewing direction.
• CTO Advisor+, €2,500 per month excluding applicable taxes. Up to 8 hours a month, weekly or biweekly sessions, priority async, and the Quarterly Technology Review. For companies where the technology decisions are arriving faster than one session a fortnight can absorb.
• Fractional CTO, from €6,000 per month excluding applicable taxes. Embedded leadership with ownership where scoped: transformation programmes, governance, board and investor work, due diligence, and hands-on execution when explicitly agreed. Contact only, scoped individually, never self-service.

Capacity is a boundary, not the value proposition. It defines the volume of substantive advisory work included each month.

• It covers meetings, the preparation for them, substantive written advice, and architecture or document review.
• It does not cover short administrative exchanges. Scheduling, logistics and quick confirmations do not consume it.
• Substantive async work is accounted in 15-minute increments.
• Async requests are normally answered within one business day. This is not an on-call or emergency-response service.
• Advice goes to your designated contacts, and the number of designated contacts is not capped.
• Unused capacity does not roll over. Work beyond the included capacity requires explicit prior agreement or a separate scope.

A rough guide. The free consultation exists to make it precise.

• CTO Advisor if the technology decisions arrive at roughly the pace of a couple a month, you already have someone competent running delivery, and what you want is a sounding board and an outside review.
• CTO Advisor+ if decisions arrive weekly, if the engineering organisation is growing, if you have board or investor conversations that need technical substance, or if you want the quarterly discipline of a structured review.
• Fractional CTO if you need someone to own something rather than advise on it: a transformation, a governance model, a due diligence process, or a turnaround.
• None of the plans if what you need is a defined piece of work designed and implemented: that is a tailored delivery engagement, scoped and priced on its own.

Because a subscription that starts badly wastes your money and my time.

The consultation does three things. It confirms there is genuine fit. It gives me enough context that the first working session is productive rather than introductory. And it fairly often establishes that you need something other than what you were about to buy.

It is free, it carries no obligation, and it is the required first step before subscribing.

Yes, and one mechanical detail is worth knowing up front: the Stripe customer portal handles cancellation, invoices and payment methods, but it is deliberately not configured for plan switching.

So a change of plan is handled directly. Tell me you want to move and we arrange it at a billing period boundary, so you are never paying for two at once.

Moving between Advisor and Advisor+ is common. Moving to Fractional CTO is a different kind of conversation, because that engagement is scoped individually rather than bought.

Work beyond the included capacity requires explicit prior agreement or a separate scope. It does not happen silently and it is never billed as a surprise.

In practice there are three routes: move up a tier, agree a one-off scope for a specific piece of work, or move to a Fractional CTO engagement if the pattern is persistent rather than occasional.

If you regularly need more than 8 hours a month, the honest recommendation is usually the third one.

• Monthly subscription, billed in advance at the start of each billing period.
• Each billing period is invoiced as a single charge and collected automatically through Stripe, using the payment method you registered.
• An invoice is issued for every billing period.
• Receipts, invoices and payment notifications are sent by Stripe, to the email address you used at checkout. TRENDev does not send billing email.

All published prices are stated excluding applicable taxes. Where VAT or another transaction tax is due, it is added to the stated price and is payable in addition to it.

The treatment depends on where your business is established and on its tax status.

• Businesses established in France are charged French VAT at the applicable rate on top of the subscription price.
• For business customers established outside France, the reverse-charge mechanism or other applicable cross-border rules may apply. You are responsible for providing accurate business and tax identification information, including a valid VAT number where applicable, and for self-assessing any tax due under a reverse charge.

In the Stripe customer portal. Sign in with the email address you used at checkout and Stripe sends you a one-time code.

Every invoice is also emailed to that address by Stripe at the moment it is issued.

If you need an invoice reissued with different business details, ask and it gets corrected at source rather than edited afterwards.

In the Stripe customer portal, using the email address you used at checkout. It is one click and it does not require contacting anyone.

You may cancel at any time, without penalty and without stating a reason. There is no minimum commitment period.

• Cancellation takes effect at the end of the current paid billing period. The service remains available until then.
• Amounts already paid for the current period are not refunded, in whole or in part, and no prorated credit is issued.
• Advisory capacity you have not used by that date is forfeited and is not compensated.

Then the capacity is carried over rather than refunded.

Where the advisory capacity of a billing period is not made available for a reason attributable to TRENDev, including absence, illness or unavailability, that capacity carries over into the following billing periods, in addition to the capacity included in those periods and at no extra charge, until it has been delivered in full or you cancel.

This is deliberately distinct from the forfeiture rule above. Capacity you chose not to use expires at the end of its period. Capacity TRENDev failed to make available carries over. You remain free to cancel at any time, including once you consider the carried-over capacity delivered.

In the Stripe customer portal, the same place as invoices and cancellation. Sign in with your checkout email address and Stripe sends a one-time code.

TRENDev never sees or stores your card details. Payment data is handled entirely by Stripe.

Three things, in this order.

• Share your context. The form on your welcome page walks you through it: company and stage, objectives for the next two or three quarters, team structure, current architecture and roadmap, and the concerns that matter most right now. It composes the email for you; none of it is mandatory, and partial answers are more useful than none.
• Book your first working session. It is used to agree priorities and to decide what the first month should actually move.
• Bring what already exists to that session. Architecture diagrams however rough, roadmap, org chart, known risks, a cloud cost snapshot. Do not create documents for the sake of it.

Here: trendev.fr/welcome.

It is deliberately kept out of search results, so it will not come up if you look for it on Google. Bookmark it, or come back to this answer, which is the permanent way back in.

Nothing is lost by having closed the tab. Everything on that page is repeatable: the context form, the booking link and the billing portal.

Stripe sends it to the email address you used at checkout, along with every subsequent invoice and payment notification. TRENDev does not send billing email, so check that address rather than waiting on a message from me.

You can also retrieve every invoice at any time from the Stripe customer portal, by signing in with that same address.

Through the scheduling link on your welcome page, which uses the same booking system as the free consultation.

Choose a convenient slot for a free consultation with TRENDev to discuss your project, your priorities and the support you need.

Useful, not required. Bring what exists:

• Architecture diagrams, however rough
• Roadmap or delivery plan
• Org or team chart
• Key technical decisions already taken, and why
• Current incidents, risks or recurring pain
• A cloud cost snapshot
• Security or compliance constraints you operate under
• Investor or board materials, where relevant

By email, at the address on your welcome page. Substantive async advice is part of what you are paying for, not an extra.

Async requests are normally answered within one business day, and priority async is part of CTO Advisor+. This is not an on-call or emergency-response service.

Short administrative exchanges, scheduling and quick confirmations do not consume your advisory capacity. Substantive work does, accounted in 15-minute increments.