The Solo Founder Technical Baseline

Three Invitations and One Uncomfortable Question

The client-digest MVP is ready for three agencies. An account manager can upload a campaign export, receive a draft explanation, review it, and send it to a client. The demonstration works. The founder has written the invitation emails.

Before sending them, the founder rehearses a less flattering version of the workflow. An import stalls after accepting the file. A digest is generated for the wrong client. A schema change damages saved work. An email provider accepts a request but never delivers the message. An account manager replies, “Where did this report go?”

The product is still small. The question is whether it is responsible enough to carry real work.

A reckless MVP is not one with a monolith, a manual review step, or three customers. It is one whose founder cannot tell that the promise failed, cannot find the affected work, cannot reverse the damage, or cannot explain what happened. The technical baseline is the smallest operating floor that closes those gaps.

Before real users depend on this product, can I ship, see, recover, support, and protect the promise well enough to keep learning?

Those five verbs are more useful than a catalog of tools. They let the founder examine the customer promise from end to end and install only the safeguards that the current risk requires.

Ship the Same Product Twice

The founder begins with the deploy path. Code, migrations, and essential configuration live in one repository. Production is reached through a hosted pipeline. The exact mechanism matters less than repeatability: a change should not depend on a command recovered from shell history or a secret remembered only by the person who typed it.

Rehearsing a second deploy exposes the real questions. Which migration runs, and in what order? Which database, storage bucket, email sender, and webhook endpoint will receive the result? Where does a failed release stop? How does the previous version return?

Local work and production do not require an elaborate ladder of environments, but they must be difficult to confuse. Production credentials belong in the deployment environment or a suitable secret store, not in source code, screenshots, chat, or support notes. They must also be replaceable. “The key is hidden” is weaker than “the key can be rotated without reconstructing the product.”

The founder then tests the paths that could falsify the experiment or break trust: sign-in, agency ownership, file import, draft generation, review, delivery, and deletion. Exhaustive coverage would be a distraction. A few repeatable checks around the promise make rapid change safer and therefore faster.

After this rehearsal, the founder can ship. That does not yet mean the founder can know what production did.

Follow One Digest Through the System

The first agency uploads a file at 09:14. The request succeeds, but the background job fails while parsing row 217. If the only visible fact is a successful upload response, a broken workflow will look like customer abandonment.

Error tracking should bring the exception to the founder. Logs should connect the upload, parsing job, agency, client, draft, review, and delivery attempt without leaking secrets or sensitive file contents. A simple health check should report when the application is unavailable; job and delivery alerts should report when the customer promise has stopped even though the website still loads.

These signals answer an operational question: what happened to this customer’s work? Product events answer a different one: did the work create value? For the digest, the useful sequence might be upload accepted, import completed, draft generated, review completed, digest sent, digest viewed, and another report created the following week. Support requests and payment state belong beside that sequence when they are part of the product.

An event is worth collecting when it helps distinguish weak demand from broken delivery. Hundreds of interface events do not compensate for missing the moment of value. The founder needs enough evidence to know whether the user arrived, crossed the activation threshold, received the promised outcome, and returned.

Recovery Is a Designed Path

Now suppose row 217 did not merely stop the job. It produced a plausible but wrong digest, and the founder discovers the defect after several imports.

A database backup is useful only if the founder knows its frequency, retention window, and restore procedure. A file backup is useful only if the original can be located and restored without confusing one agency’s data with another’s. Generated output may be recoverable by regeneration, but only if the founder understands whether a second run will produce the same result and whether the original must be preserved for explanation.

Recovery is larger than restoring a database. The safest response may be to return to the previous release, disable sending, pause an import job, restore a configuration value, quarantine affected records, or run a tested repair migration. Payment and email failures may require pausing the flow, notifying customers, and reconciling provider state with product state.

For the digest product, the founder adds a way to identify imports produced by the faulty parser, keeps the original files, and rehearses rerunning one import after correction. A feature switch can pause delivery while review continues. The important thing is not the switch itself; it is that the failure has a bounded set of records and a known route back to a trustworthy state.

Early products often contain manual work, scripts, and administrative interventions. Those are reasonable. Unrecorded interventions are not. If a founder can change customer state, the product needs enough history to say what changed, who was affected, and whether the repair completed.

Support Without Database Surgery

The first support message is not a post-PMF event. It is a customer trusting the product enough to ask for help.

Users need an obvious route to the founder: an email address, support form, shared inbox, private channel, or another channel that will actually be watched. The founder needs an equally clear route from the message to the relevant account and workflow.

For this product, a small admin page shows agency and client ownership, the received file, import status, blocking error, digest state, review history, delivery attempt, and recent founder action. It can answer “Did my import run?”, “Which client received this?”, and “Why can’t this person see the report?” without a blind production edit.

Direct database access may still be available for exceptional diagnosis. It should not be the normal support interface. Repeated custom queries reveal a missing operating surface; repeated table edits turn customer support into an unlogged source of data corruption. The founder does not need to build an internal product. The founder needs enough visibility and bounded action to help a customer safely.

Protect What the User Is Asked to Risk

The baseline should grow with the promise, not with anxiety. A private habit tracker and a B2B product that stores client exports, sends external messages, and accepts payment do not create the same obligations.

Authentication establishes who is acting. Authorization establishes which agency, client, file, digest, and billing record that person may reach. A managed identity service can handle sign-in while the product still owns these boundaries. An implementation may be simple; ownership cannot be vague. The next data-model decision will have to make those actors and relationships explicit.

If the MVP charges, the founder must be able to follow checkout, invoice, provider notification, entitlement, cancellation, refund, and failed payment through the product. Outsourcing card handling does not outsource the customer’s question about why access appeared or disappeared.

Privacy begins by declining data the current promise does not need. For the data that remains, the founder should be able to explain where it is stored, who can reach it, how it appears in logs and support attachments, how long it remains, and what export or deletion means at this stage.

Security basics follow the same risk. Use maintained dependencies. Require encrypted transport in production. Keep secrets out of code and logs. Validate file uploads, imports, webhooks, and admin actions. Check authorization at every account and data boundary. Limit production access, including the founder’s own, to what the work requires.

This is not a miniature security department. It is an honest response to the trust the product asks a customer to extend.

The Minimum Technical Baseline

Record the baseline in one page that can be used during a launch or an incident. Each line should name the actual path, owner, or procedure rather than claim that a category is “handled.”

Ship

• Code, migrations, and essential configuration are under source control.
• Deployment and migration follow a repeatable path, with production clearly separated from local or test work.
• Secrets stay outside source and can be rotated.
• The workflows whose failure would break value or trust have repeatable checks.

See

• User-facing exceptions reach the founder.
• Logs can reconstruct the critical workflow for one customer without exposing sensitive contents.
• Availability, critical jobs, and external delivery can fail visibly.
• A small event sequence shows activation, value delivery, return use, support, and payment where relevant.

Recover

• Important records and files can be restored, exported, or intentionally regenerated, and one restore has been rehearsed.
• Bad code, configuration, jobs, migrations, imports, and automated delivery have a practical stop or reversal.
• A repair can identify affected records and leave an account of what changed.

Support

• Users know how to ask for help, and the channel is watched.
• The founder can inspect account, workflow, failure, permission, delivery, and billing state without blind database edits.
• Manual or administrative actions that affect customer work leave enough history to investigate.

Protect trust

• Authentication identifies the actor; authorization enforces the current ownership boundaries.
• Payment state is traceable when money is part of the promise.
• Data collection, storage, access, retention, export, and deletion can be explained.
• High-risk inputs and actions are validated, dependencies are maintained, transport is encrypted, and production access is limited.

Add a short runbook: how to deploy, inspect a failure, pause the risky path, restore or repair, contact affected users, and resume. Write it for the version of you who is tired and already handling the support message.

Narrow the Promise or Repair the Gap

Run one real customer journey against the baseline before inviting broader use. Mark each line present, weak, missing, or not applicable. For every weak or missing line, finish the sentence: “If this fails, then I cannot…” The answer should name a customer consequence, a lost piece of evidence, or an unsafe recovery.

Then choose the smallest repair that restores the missing capability. Sometimes the repair is a backup rehearsal or an alert. Sometimes it is a support view. Sometimes the honest move is to narrow the launch: accept one file type, review every output, postpone payment, retain fewer data fields, or serve fewer accounts until the boundary is safe.

The baseline is ready when the founder can ship, see, recover, support, and protect the current promise without building an operations organization around an unproven product. It keeps a failure in delivery from masquerading as a verdict on demand. That is what makes the next evidence worth trusting.