Pre-PMF Architecture Blueprint

Draw What You Must Be Able to Operate

A customer reports that they submitted work twenty minutes ago and nothing happened. Can you find that customer’s request, see where it stopped, repair it without corrupting another record, and tell whether the repair succeeded?

That question is more useful than asking whether an early architecture will scale. Before product-market fit, the system needs to deliver one valuable outcome reliably enough to earn continued use and expose what customers actually do. It also needs to remain understandable to the one person who deploys it, supports it, and changes it.

Use this blueprint before committing to the first production shape, or when a prototype is acquiring customers and hidden operating work. It is not a complete inventory of technology. It is a drawing of one customer promise and the machinery required to keep it.

The blueprint is sufficient when you can use it to explain five operations:

• deploy a change without guessing which parts will move;
• observe a failed customer outcome;
• inspect and repair one customer’s state;
• recover essential data; and
• make the next likely product change without crossing a maze of boundaries.

If one of those operations is vague, the answer may be a small test, an admin action, a backup drill, or a simpler boundary. It is not automatically another service.

Begin With the Promise, Not the Components

Choose one decision window and one customer outcome. “Design the platform” has no stopping condition. “Support three paid pilots that turn an uploaded export into a reviewed report delivered within one business day” gives the architecture work to do.

Write the boundary before drawing boxes:

Decision window:
Customer and user:
Outcome they must receive:
Evidence this system must help us collect:
Current trust promises (access, privacy, retention, recovery, delivery):
Expected range of users, records, file sizes, and expensive operations:
Founder response constraint (for example, can repair a failed job in 20 minutes):
Next product change we already consider plausible:
What this blueprint deliberately does not serve:

Use ranges supported by the next test, not imaginary precision. The expected range is a design input; it is not a forecast of success. Trust promises are different. If customers are entitled to private access or recoverable records now, low traffic does not make those obligations optional.

Trace One Value Path

Draw the path a real piece of work follows. Begin at the customer’s action and continue until the promised outcome is visible to them. Put the authoritative record on the page, not merely the user interface. Show work that happens later, data that leaves your control, and the path by which the founder inspects or repairs state.

A useful first sketch may be this small:

customer action
      |
      v
entry point -> identity/access -> application -> source of truth
                                      |              |
                                      v              v
                               background work    file storage
                                      |
                                      v
                               external service -> delivered outcome

founder repair path -> customer record -> job history -> safe retry/correction

Replace these labels with named responsibilities. “Application” is acceptable when one deployable application owns the workflow; inventing internal services to make the diagram look architectural is not. Draw a separate boundary only when it has a consequence: independent failure, a different data owner, a separate deployment, material usage cost, or an external promise you cannot enforce yourself.

For each component that remains, write one short annotation:

Name and responsibility:
Data it reads or writes:
How failure becomes visible:
How the founder inspects or repairs it:
What customer promise depends on it:
Why it must exist in this decision window:

Then mark the system of record for each essential fact. If the database says a report is complete while an external provider says it failed, which state governs the customer’s experience? If a file exists in storage but its database record was deleted, is it recoverable customer data or an orphan to remove? Ambiguous authority turns ordinary support into forensic work.

Walk the Blueprint Under Pressure

The happy path proves that the boxes connect. These five walks reveal whether one founder can run them.

A customer outcome fails

Start with a particular customer and a particular operation. Find it using information available from the support request. Follow its identifier through application logs, job state, external calls, and delivery. Name what can be retried, what must be idempotent, what requires a manual correction, and how you verify the final state.

Do not accept “check the logs” as a repair path. The blueprint should identify the log or error record, the customer or operation identifier, the state transition that failed, and the action that restores a valid state. If repair requires direct database edits, record that as risk and define the constrained admin action you need before the pilot grows.

A deploy goes wrong

Trace code from the reviewed change to production. Record the deploy unit, configuration source, migration order, health signal, and rollback or forward-fix path. A single deployable application is often an advantage here: it reduces the number of versions and boundaries one operator must coordinate. It is not a license to make irreversible schema changes.

Primary data is lost or damaged

Name what is backed up, where the backup is isolated, how long it is retained, and how restoration is tested. Then follow restored data through files, job state, and external systems. “The provider makes backups” describes a feature. A dated restore drill with a measured result is recovery evidence.

A customer needs inspection or correction

Follow the founder’s support path without relying on production shell access and improvised queries as the permanent interface. Identify the minimum admin view or command needed to find the account, see relevant history, correct allowed state, and record who made the change. Sensitive actions still require access control and an audit trail even when the same founder currently wears every role.

The next product change arrives

Use the plausible change named in the boundary. Follow the responsibilities it touches. If a modest change crosses several independently deployed services, duplicate data models, or vendor-specific workflows, the blueprint has found a change tax before customers have agreed to pay for it. Simplify the boundaries or test the assumption that created them.

Record the result of each walk:

Walk:
Starting event:
Path through the system:
Evidence available now:
Founder action:
Proof that the action worked:
Missing capability or unsafe step:
Smallest correction or test:

Decide What You Will Depend On

Managed databases, authentication, payments, email, hosting, and file storage can remove work that does not differentiate the product. They do not remove responsibility for the customer promise. For each external service on the value path, record the failure you must observe, the data or state you can retrieve, the cost path you can bound, and the fallback appropriate to the current promise.

The fallback need not be a second provider. Early on it may be a visible failed state, a controlled manual delivery path, exported data, and an honest customer message. What matters is that the provider cannot fail while your system continues to claim success.

Prefer one source of truth, one normal deploy path, and one way to trace a customer operation unless the product evidence demands more. Background work, search, analytics, and feature flags should begin as the smallest mechanisms that satisfy a demonstrated need. Each additional independently failing part spends the same founder attention needed for discovery and support.

A Filled Blueprint: Reviewed Agency Reports

Consider the reporting product from the stack scorecard. During the next three paid pilots, an agency uploads a campaign export and receives a reviewed report within one business day. The product must preserve the upload and delivery history, let the founder inspect every generation, and reveal whether the report was accepted or revised. It does not yet need self-serve customization, real-time collaboration, or many report formats.

The founder draws one server-rendered application with a managed relational database as the source of truth. Managed object storage holds the original export and generated report; database records hold ownership, version, processing status, and storage references. One background-work path invokes the report-generation provider. The result returns to the application for founder review, and an email provider sends the approved delivery. A small admin view exposes the customer, input, generation attempt, review status, delivery record, and allowed retry action.

This is not the fewest possible boxes. Removing the job record would make a failed generation hard to distinguish from work that never began. Removing the review state would erase the human step promised by the pilot. Splitting upload, generation, review, and delivery into separate services would add deployment and tracing boundaries without producing better product evidence.

The failure walk changes the design. The generation request receives an operation identifier before the provider call. Each attempt records its status and provider reference. A retry reuses the same logical operation and cannot create a second approved report silently. Provider success does not mark the customer outcome complete; founder approval and recorded delivery do.

The recovery walk also finds a gap: database backups alone cannot restore the uploaded exports. The founder adds object-version retention appropriate to the customer promise and performs a restore drill using one representative account. The drill checks that database rows, stored files, and ownership still agree. Only then can the blueprint claim a recovery path.

The next likely change is a second report format. It alters the generation and review logic inside the application but does not require a new service or data authority. If measured generation volume later blocks ordinary requests or provider cost breaks the product model, those observations become review triggers. Hypothetical popularity does not.

Finish With Decisions and Evidence

Place the drawing and the pressure walks in one architecture record. End it with decisions rather than a component wish list:

Chosen shape for this decision window:
Why it is sufficient for the customer promise:

Authoritative data and ownership:
External promises and failure handling:
Deploy and migration path:
Observation and founder repair path:
Backup and tested recovery path:

Complexity explicitly deferred:
Risk we accept for this window:
Unknown that must be tested before relying on it:
Next test or operating improvement:

Review when this evidence appears:
Owner and date of the last failure/restore/deploy walk:

Reject the blueprint if it depends on dashboards no one has configured, backups no one has restored, manual work no one has timed, or data ownership no one can explain. Those are hypotheses. Convert the most consequential one into a small exercise before adding architecture around it.

The finished blueprint should let a skeptical future reader point to the customer promise, follow the data and work that fulfill it, see how failure becomes repair, and understand why every present boundary earns its cost. Everything else can wait for evidence.