Minimum Technical Baseline Checklist

A Baseline Is a Promise You Can Recover

A small product does not need miniature versions of every system a large company owns. It does need a responsible answer when the narrow thing it promises goes wrong.

Imagine a customer uploads a file and expects a report by morning. A successful demo proves the happy path once. A technical baseline answers harder questions: Can another customer see that file? Will a failed job become visible before the deadline? Can the founder restore the report after accidental deletion, reverse a bad deployment, and tell the affected customer what happened?

Use this checklist before inviting real users, accepting important data, taking payment, or making a workflow dependable. It is a launch gate, not an architecture wishlist. The evidence should show that one founder can deploy, observe, protect, recover, support, and improve the product at its present scale.

Define the Launch Boundary

First, write the promise being placed under load. “The MVP works” is too broad to inspect.

Launch window:
Users or accounts invited:
Value promised to them:
Critical journey from first action to delivered value:
Customer data, money, or external systems involved:
Maximum tolerable interruption or data loss:
Manual fallback, if one exists:
Founder availability during this window:

The boundary controls the baseline. A private prototype using disposable sample data has different obligations from a paid pilot holding customer records. The second case may still have ten users, but its access, recovery, privacy, payment, and support paths must be real.

Run the Seven Demonstrations

Do not mark a capability complete because a service is configured or a library is installed. Run a small demonstration and keep the result. For each gate, record ready, limited, or hold, plus the evidence and the next action. A limitation is acceptable only when its boundary is explicit and the promised journey remains responsible.

1. Reproduce and deploy the product

Starting from the repository, confirm that future you can identify the deployed version and ship a known change through a repeatable path. Production configuration and secrets must not depend on an unrecorded shell history or values embedded in source control.

Demonstrate one deployment, then redeploy or roll it back. Record the source revision, deployment command or pipeline, production configuration owner, secret store, smoke check, and rollback route. If the founder cannot tell what is running or cannot restore the prior working version, hold the launch.

2. Keep users inside their own boundary

Test with at least two ordinary accounts. Try to read or change one account’s protected resource while authenticated as the other. Exercise the same authorization rule through the user interface and any direct API or object URL that exposes it.

Record how identity is established, where authorization is enforced, how sessions or credentials are revoked, and which inputs cross a trust boundary. If the product has founder administration, use a separate, limited path rather than granting every request ambient production power. Record sensitive administrative actions well enough to reconstruct a mistake.

Authentication is necessary only where the promise requires identity. Authorization is necessary wherever identity changes what a user may see or do. A working sign-in screen does not prove the second property.

3. Recover the state customers would miss

Inventory the state required to deliver the promise: primary records, uploaded files, generated work, configuration, and the product-side record of payment or external delivery. Name the authoritative copy of each item and any managed service that holds it.

Create a backup or export, restore it into an isolated location, and inspect a representative record or file. Record when backups run, how failures become visible, what period could be lost, who can restore, and the last successful restore test. A backup that has never produced readable state is an intention, not recovery evidence.

Also record the data boundary: what is collected, why it is needed, who receives it, how access is removed, and how deletion or retention requests are handled. If the product cannot state where sensitive customer data goes, hold the launch until it can.

4. Notice failure before support becomes monitoring

Cause a safe failure in the critical journey. Confirm that it reaches error tracking or an alert with enough context to identify the affected operation without placing secrets or unnecessary personal data in logs. Follow the signal from the customer-visible symptom to the failing step.

Record the alert destination, error context, log location and retention, health or journey checks, and the time in which the founder expects to notice a serious failure. Infrastructure health alone is insufficient: a server can return 200 while reports remain stuck in a queue or emails never arrive.

5. Repair one customer without editing the database blindly

Choose a plausible partial failure: a job completed but delivery failed, a payment succeeded but entitlement did not change, or an import stopped halfway. Demonstrate how to inspect the customer’s state, retry or correct the operation safely, and record what was changed.

The repair path may be a small admin screen, a constrained script, or a provider console. It does not need to be elegant. It does need limited access, validation, confirmation for destructive actions, and a durable trace. If the only repair method is an improvised production query whose effect cannot be reviewed, the baseline is not ready.

6. Reach users and receive support

Send a test message through the support channel and confirm that it reaches a place the founder actually watches. Prepare a way to identify affected users and contact them when a material incident changes the value, timing, security, privacy, or money they were promised.

Record the public support route, expected response window, status or incident message location, customer contact source, and escalation boundary. A founder can offer a narrow support window; silently offering no reachable support is different.

7. Observe whether the product delivered value

Name the few events that distinguish arrival, meaningful progress, delivered value, and failure in the critical journey. Trigger them with a test account, then find the resulting record. Analytics should answer the current product question without collecting data merely because it might become useful.

Pair those events with the smallest tests that protect the most consequential rules: authorization boundaries, money or entitlement transitions, important calculations, and the critical happy path. Document the commands, dashboards, provider boundaries, and unusual operational facts future you will need during a failure. The baseline is complete when it supports learning and change, not when it freezes the first version in place.

Record the Gate

Use one block for each demonstration. Link to evidence that will still make sense after the launch window ends.

Gate:
State — ready, limited, or hold:
Demonstration performed:
Result and evidence location:
Customer consequence if this fails:
How failure becomes visible:
Founder repair or fallback:
Known limitation and its boundary:
Owner:
Next action:
Recheck trigger or date:

Then make one launch decision:

Launch decision — ready, limited launch, or hold:
Users and promise covered by this decision:
Evidence reviewed:
Limitations explicitly accepted:
Conditions that stop the launch:
First support and monitoring watch:
Decision owner and date:

A limited launch is a real operating mode, not softer language for uncertainty. It might cap the pilot at three accounts, exclude sensitive files, require the founder to watch each delivery, or promise business-hours support. State the limit where users can rely on it, and define the signal that permits expansion.

Worked Gate: The Morning Report

Suppose three agencies are invited to upload campaign exports and receive a reviewed report by 09:00 the next business day. The product stores client performance data, calls an external model, and emails a link to the completed report.

The founder first tests two agency accounts and discovers that a report URL is protected only by an unguessable identifier. That is a hold, not an acceptable beta shortcut: possession of the URL is doing work that account authorization should do. The founder adds an account check at the report boundary and tests both the page and direct download again.

Next, the founder deletes a test report and restores the database record from backup. The uploaded file lives in separate object storage and was not included in the recovery plan. The launch becomes limited: agencies retain their source exports, and the support promise says a file may need to be uploaded again. Before expansion, storage versioning or a tested file backup must remove that limitation.

Finally, the founder forces the model call to time out. Error tracking records the job identifier, but no alert fires and the dashboard still counts the upload as activation. The founder changes the value event to report_delivered, alerts on jobs that miss their deadline, and writes a constrained retry command. A smoke test confirms the last working release can be redeployed, and a support message reaches the watched inbox.

The result is not a claim that the system is generally “production ready.” It is a bounded decision: three agencies, defined data, one delivery promise, known file-recovery limits, and a founder who has rehearsed the failures most likely to break that promise.

What the Checklist Must Not Hide

A managed provider can supply authentication, payments, storage, email, analytics, or error tracking, but the founder still owns the product boundary around it. Record provider failure, export, access, and replacement paths in proportion to the customer promise.

Likewise, passing every low-risk item cannot compensate for one catastrophic gap. No amount of deployment polish makes cross-account data exposure acceptable. A perfect analytics taxonomy does not rescue a product that cannot restore the state it promises to keep. Let trust and irrecoverable harm override the convenience of a high completion count.

The baseline should remain small. Remove controls that do not protect the current promise, produce necessary learning, or give the founder a workable recovery path. Add a control when the launch boundary changes: more sensitive data, money, integrations, automation, users, or dependence can turn yesterday’s reasonable limit into today’s reckless one.

The checklist has done its job when the founder has watched the product fail in representative ways and can still explain how the customer promise will be kept, repaired, or honestly withdrawn.