← Think Like a CTO: Architect Your Product with AI
Think Like a CTO · Module 2 · the Decision Lab
Same product, different conditions.
Technical architecture is about trade-offs. Change your product's conditions and watch how a CTO's advice changes. Nothing you choose is stored or sent.
Suggested starting point
Modular monolith on a managed platform
CTO discussion points
- Architecture
- Start with a simple modular application and managed services where suitable. Validate customer demand before adding distributed-system complexity.
- Security and data
- Establish the baseline: strong sign-in, role-based permissions, secrets kept out of the code, encrypted connections, tested backups and a simple privacy notice.
- Operations and team
- Favour low operational overhead, managed infrastructure, documented decisions and limited technology diversity. Every extra tool is something you must patch at 2am.
Watch out
Ask your Virtual CTO What is the smallest architecture that lets us test our riskiest assumption?
Copied. Paste it into ChatGPT, Claude or Gemini after the master prompt.
How to use it
- Set the conditions that match your product today, and read the advice.
- Change one setting at a time. Notice which advice changes, and which never does: the security baseline applies at every scale.
- Press Copy as a Virtual CTO prompt and paste it into your Virtual CTO conversation. It will ask about your product and test this advice against it.
The Decision Lab is a teaching aid, not a design tool. It shows how conditions shape a CTO's thinking; your own product needs its own decisions, and anything involving sensitive data needs a qualified specialist.
The Virtual CTO master prompt
Paste this first, in a new conversation, then paste your Decision Lab settings.
Act as my Virtual CTO: a pragmatic CTO and principal software architect advising a non-technical product leader. Your job is to help me make sound technical decisions, not to agree with every proposal. First, ask me about these, one question at a time, and wait for each answer: - Product vision and target users - Core workflows and MVP scope - Data sensitivity and integrations - Expected usage and growth - Budget, team and time to market Then: 1. Propose the simplest architecture that meets my needs. 2. Compare two or three realistic technology alternatives. 3. Explain each trade-off in plain English. 4. Identify security, privacy and operational risks. 5. Separate what the MVP needs from what can wait. 6. Draw the architecture as a text or Mermaid diagram, and keep a decision log: decision, reason, alternatives, consequences. 7. Create a phased technical implementation plan. Rules: - Challenge unnecessary complexity, including mine. - Give costs as ranges, with the assumptions behind them. Never invent prices, figures or customer evidence. - Flag anything involving children's, health, financial or other regulated data for specialist review. - State your assumptions and uncertainties, and say which decisions need a qualified engineer, security or legal review.