← Think Like a CTO: Architect Your Product with AI The workbook · My Product Architecture Blueprint

Every technical decision, written down and defended.

Twelve sections, each with a short explanation, a worked TutorDesk example and space for your own product. Your answers are saved in this browser as you type: nothing is sent to us. Export it as a PDF and take it to your review board, your developers or your investors.

0 of 12 sections started

My Product Architecture Blueprint · Think Like a CTO: Architect Your Product with AI · MVP Studios Academy

1 01 · Exercise 1

Product context and business objectives

A CTO starts with the business, not the technology: who the product serves, what it must achieve and what limits the team works within.

See the TutorDesk example

TutorDesk: a booking and payments tool for independent tutors. 2,000 tutors and about 30,000 parents today; goal: 10,000 tutors in 18 months. Team: the founder and two contract developers. Budget: about £6,000 a month for engineering and running costs.

The product in two sentences Business objectives for the next 12–18 months Constraints

Ready? The objectives are measurable I've named the real constraints, including budget and team

1 02 · Exercise 1

Functional and non-functional requirements

Functional requirements say what the product does. Non-functional ones, the quality attributes, say how well: fast, available, secure, affordable. They drive most architecture decisions.

See the TutorDesk example

Five technical priorities: 1 protect children's lesson data; 2 bookings and payments never lost; 3 calendar sync within a minute; 4 available 99.5% of the time in UK evenings; 5 running costs under £1 per tutor per month.

Core workflows the product must support Your five technical priorities, in order What you are deliberately not optimising for yet

Ready? Each priority is tied to a business objective The order is a real choice, not a wish list

2 03 · At home

Architecture principles and constraints

Principles are the rules your team decides by when you're not in the room. Five good ones settle a hundred small arguments.

See the TutorDesk example

Simplest thing that works; buy before build for anything that isn't TutorDesk's core; one main database; collect the least personal data possible; every decision written down.

Your five architecture principles Technical constraints you must work within

Ready? Each principle would actually rule something out

2 04 · Exercise 2

System context and component diagrams

The context diagram shows the product, its users and the outside systems it talks to. The component diagram shows what's inside. If you can't explain a box, it shouldn't be there.

See the TutorDesk example

Context: parents and tutors use TutorDesk; it talks to a payment provider, Google and Outlook calendars and an email/SMS service. Inside: one modular web application (bookings, payments, calendars, accounts), one database, a background job runner.

Architecture style chosen, and why System context: users and external systems Main components and what each is responsible for The alternative you rejected, and why

Ready? I can explain every box in one sentence I chose the simplest style that meets my priorities

3 05 · Exercise 3

Technology stack and build-versus-buy decisions

Choose technology your team can hire for, run and afford. Build what makes you different; buy or rent the rest, and know what it would cost to leave.

See the TutorDesk example

Python/Django web app; PostgreSQL; a managed platform for hosting. Buy: payments, email/SMS, sign-in with Google. Build: the booking rules and tutor dashboard, which are TutorDesk's core. Lock-in risk: the payment provider holds card details, so moving would take about a month.

Chosen stack: language and framework, database, hosting Decision matrix summary: options, criteria, scores Build versus buy, per capability Lock-in and technical debt you accept

Ready? Every choice has a reason I could defend I know the exit cost of each major vendor

3 06 · At home

Data architecture and integration design

Data outlives code. Know what you store, who owns it, how long you keep it and how it moves between systems.

See the TutorDesk example

Stores: tutors, parents (first name, email), lesson slots, bookings, payments references. Never stored: card numbers (the payment provider holds them) or a child's full name. Integrations: calendar sync every minute, payment webhooks, email/SMS sending. Bookings kept for 2 years.

Main data and who owns it Sensitive or personal data, and what you will not collect Integrations: what moves, how often, what happens if it fails How long you keep data, and how it is deleted

Ready? I've removed data I don't need Each integration has a plan for when it fails

4 07 · Exercise 4

Security, privacy and compliance requirements

Security is designed in, not bolted on. Start with the threats that matter for your data, then choose controls in proportion.

See the TutorDesk example

Top threats: a parent seeing another family's lessons; a stolen tutor password; a leaked database backup. Controls: strict per-tutor permissions, two-factor sign-in for tutors, encrypted backups, secrets in a vault. Compliance: UK GDPR; data about children needs a data protection impact assessment; payments via a PCI-compliant provider.

Top threats (who might attack, what they want) Controls: access, encryption, secrets, backups Privacy and compliance obligations

Ready? I've named who can see what Anything regulated is flagged for specialist review

4 08 · At home

Scalability, availability and recovery requirements

Design for credible growth, not fantasy scale. Decide how much downtime and data loss the business can survive, then build for exactly that.

See the TutorDesk example

Expected load: 10,000 tutors, peaks on Sunday evenings of about 50 bookings a minute. Availability target: 99.5%. Recovery: back online within 4 hours (RTO), lose at most 15 minutes of bookings (RPO). Plan: one app server that can be doubled, managed database with point-in-time recovery.

Expected load now and in 18 months Availability, recovery time (RTO) and data loss (RPO) targets How you will meet them, and what you will monitor

Ready? The targets come from the business, not a template I've tested, or planned to test, a restore

6 09 · At home

Infrastructure and operating-cost assumptions

A CTO knows what the product costs to run, per customer, and what makes that number move. Use ranges and write down every assumption.

See the TutorDesk example

Hosting £150–£300 a month; database £50–£150; email/SMS £100–£400 depending on reminders sent; monitoring £0–£50; payment fees passed on to tutors. About £0.15–£0.45 per tutor per month. Assumptions checked against the providers' own price calculators.

Monthly running costs, as ranges Cost per customer, and what drives it Assumptions, and how you checked them

Ready? Costs are ranges with assumptions, not single guesses I checked them against real price lists

5 10 · Exercise 5

Development, testing and deployment approach

How the team works decides how fast and how safely the product changes. Make releases small, tested and reversible.

See the TutorDesk example

Code in Git with reviewed pull requests; automated tests on every change; three environments (development, staging, production); deploy from the main branch several times a week; error alerts to the founder's phone; a written rollback step.

Code, review and branching Testing approach Environments, CI/CD and release controls Monitoring, incidents and support Production-readiness checklist

Ready? A bad release can be undone in minutes Someone is told when production breaks

4 11 · Exercise 4 and Exercise 6

Technical risks and architecture decision records

A decision record says what you decided, why, what you rejected and what it will cost you later. The risk register says what could go wrong and what you are doing about it.

See the TutorDesk example

Risk: calendar sync fails silently and tutors are double-booked. Likelihood medium, impact high. Mitigation: sync health check and a daily email of conflicts. Decision record: modular monolith, not microservices, because a team of three can't run many services; revisit at 20 engineers.

Risk register: risk, likelihood, impact, mitigation, owner Architecture decision records: decision, reason, alternatives, consequences

Ready? Every high risk has an owner Each decision says when to revisit it

6 12 · Exercise 6

Implementation roadmap and CTO sign-off checklist

A roadmap turns the architecture into phases the business can fund. The sign-off checklist is what you defend at the CTO review board.

See the TutorDesk example

Phase 1 (months 1–2): accounts, bookings, payments, backups. Phase 2 (3–4): calendar sync, reminders, monitoring. Phase 3 (5–6): reporting, scale tests. Specialist review: a penetration test and a data protection review before phase 1 goes live.

Phases, with what each delivers and costs Decisions needing specialist review Review board feedback, and what you'll change

Ready? Phase 1 is the smallest version that meets my priorities I defended my decisions at the review board AI advice that matters has been checked by a person

Your answers are stored only in this browser on this device. Don't enter personal details about other people. To move to another device, export a PDF.