The first CTO decisions: start with the workflow, not the stack

What should a founder ask a CTO first?

Ask how the business will complete its most important customer journey. A list of tools cannot answer that question. The useful starting point is a concrete outcome, such as an expert consultation that has been booked, delivered and paid for, or a credit application that reaches the institution responsible for a decision.

Calledge combines discovery, scheduling, video consultation, payment and invoicing. FABA Finance connects borrowers with institutions through origination and routing. These project descriptions illustrate why architecture has to follow the entire journey. The following brief is a recommended way to reason about that journey, rather than a claim about either project’s internal implementation.

Write a brief that makes uncertainty visible

Start with a single page that answers these questions:

1. What outcome is the customer paying for? Describe a completed result that somebody can verify.
2. Who owns each decision? Name the customer, operator, platform and external provider wherever responsibility changes.
3. Which information is authoritative? Decide which system owns a booking, a payment or an application status.
4. What can fail? Include unavailable providers, incomplete inputs and a user abandoning the flow.
5. What must the first release respect? Record data access, operational capacity, delivery budget and any requirements supplied by the responsible domain experts.

This brief becomes an architecture input and a product acceptance checklist. It also gives the team somewhere to disagree before a disagreement turns into code.

Review the boundaries before adding components

An architecture diagram should make responsibilities easier to explain. If it merely names services, it leaves the hardest questions unanswered.

Consider a consultation platform. A confirmed calendar slot, a successful payment and permission to join a call are separate facts. Which fact authorizes the next step? What should an operator do if a customer paid but the booking confirmation failed? Those questions establish the boundaries that the implementation must respect.

The AWS Well-Architected Framework provides a useful set of lenses for reviewing system tradeoffs, including reliability, security and cost. A small product still needs those conversations. The depth of the implementation should match the actual operating risk.

Separate costly decisions from reversible ones

Prioritize choices that shape data ownership, authorization and the product’s commercial model. They can influence many later changes. A visual detail or an internal helper usually has a smaller reversal cost.

For example, sharing a deployment across customer brands raises questions about tenant access from the beginning. OWASP’s guidance on object level authorization requires checking whether the current actor may perform the requested action on the requested record. An unpredictable record identifier is not a substitute for that check.

In an architecture review, ask for the evidence behind each decision: the constraint, the alternatives, the owner and the condition that would justify revisiting it. Keep the record short enough for the team to use.

What should the first technical plan contain?

A useful plan connects one product outcome to its dependencies, failure handling and acceptance criteria. It identifies who will decide the unresolved questions and what can wait. It should let a founder understand the next step and let an engineer begin implementing it.

If the plan needs an elaborate system before the core journey can be demonstrated, challenge the scope. The first release should be small enough to operate and complete enough to teach the team something real.