What Belongs in Week One of an MVP

Week one determines whether a software build completes in twenty-eight days or drifts into month four.

When early-stage projects fall behind schedule, the delay rarely comes from complex database queries or difficult infrastructure. The delay happens because the team spent the first seven days polishing secondary surfaces before verifying the central transaction.

Founders often start a project by sketching user settings, profile picture uploaders, dark mode toggles, and team invite modals. These features feel like progress because they look like complete software in a browser. None of them prove that a stranger will use the product or pay for the outcome.

In our Build Sprints, we follow a strict seven-day sequence. If the central data path does not run on staging by the end of day five, the project will not hit its day twenty-eight launch target.

---

The trap: building the perimeter first

Most software products have a core transaction and a perimeter.

The core transaction is the specific mutation that produces the primary value. In an accounting tool like Ankik, the core transaction is posting a balanced ledger entry that updates accounts. In a dispatch tool, it is assigning a driver to a pickup route. In a retention platform like Retainix, it is logging customer activity at the counter and updating points balance.

The perimeter includes everything else:

• Password resets and email verification flows
• Profile pictures and bio fields
• Multi-organization permission matrices (owner, admin, member, viewer)
• Theme preferences and notification preferences
• Account deletion workflows

Teams build the perimeter first because it is familiar. Writing a user settings form is comfortable. Designing the data model for a complex domain requires difficult trade-offs.

Building perimeter features first creates an illusion of velocity. By day seven, the repository has forty commits and twelve visual components, but the product cannot complete a single customer job. When the team finally tackles the core workflow in week three, they discover that their initial database assumptions were incorrect. They must rewrite the auth boundaries, rework the models, and discard days of perimeter interface code.

---

The seven-day week one schedule

We treat week one as a sequencing test. The objective is to have a stranger complete the central mutation on a live staging server before the first weekend.

flowchart TD
    D1["Day 1: Single Mutation Contract<br/>(One actor, one mutation, one outcome)"] --> D2["Day 2: Relational Schema<br/>(PostgreSQL tables, foreign keys, integer cents)"]
    D2 --> D3["Day 3: Tenant & Auth Boundary<br/>(Session cookie, organization_id scoping)"]
    D3 --> D4["Day 4: Core Endpoint & Tests<br/>(Happy path and rejection integration tests)"]
    D4 --> D5["Day 5: Bare Interactive Surface<br/>(Plain server-rendered HTML form on staging)"]
    D5 --> D6["Day 6: Automated CI/CD Pipeline<br/>(Git push deploys to HTTPS in under 4 minutes)"]
    D6 --> D7["Day 7: The Cold Stranger Test<br/>(External user finishes job without walkthrough)"]

Day	Focus	Milestone Output	Verification Gate
Day 1	Single mutation contract	One-page technical specification	Can the outcome be defined in one sentence?
Day 2	Relational schema	Migration scripts in PostgreSQL	Do tables have strict foreign keys and checks?
Day 3	Tenant & auth boundary	Session cookie and tenant middleware	Does every query require an organization identifier?
Day 4	Core endpoint	Automated API integration test	Does the test assert balanced state after mutation?
Day 5	Bare interactive surface	Server-rendered form on staging	Can an external tester submit valid data?
Day 6	Automated CI/CD pipeline	Continuous deployment on git push	Does staging update within four minutes of push?
Day 7	The cold stranger test	Screen recording of unassisted run	Did the tester finish without asking for guidance?

---

Day 1: The single mutation contract

Before opening an editor, we write down the single mutation that defines the application.

This contract must fit into one sentence:

“When an authenticated manager submits an invoice, the system writes a draft record, assigns an incremental sequence number, and recalculates the customer balance.”

If defining the mutation requires three sentences, the project is trying to ship three distinct products at once. We remove secondary actions until only one remains. Multi-currency support, PDF export, and email delivery belong to later phases.

---

Day 2: Relational schema and integrity

On day two, we write the PostgreSQL schema directly. We avoid abstract ORM schema generators that hide database behavior.

We enforce strict data integrity from the first commit:

• Foreign keys with explicit ON DELETE RESTRICT rules to prevent orphaned records.
• Integer storage for financial amounts to eliminate floating-point rounding errors.
• Check constraints on status fields rather than loose text columns.
• Timestamps with timezone (timestamptz) on every record.

CREATE TABLE organizations (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE ledger_entries (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE RESTRICT,
    account_code TEXT NOT NULL,
    amount_cents BIGINT NOT NULL,
    entry_type TEXT NOT NULL CHECK (entry_type IN ('debit', 'credit')),
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_ledger_org_account ON ledger_entries(organization_id, account_code);

Fixing schema errors on day two costs twenty minutes. Fixing schema errors after building twelve UI screens takes two days.

---

Day 3: Authentication and tenant boundaries

You cannot test return visits or user retention without identity. Mock authentication in localStorage hides security defects and tenancy bugs that break production environments later.

On day three, we set up real session management. Every query executed by the application must accept an organization identifier. We write automated tests to verify that tenant A cannot access records belonging to tenant B, even when guessing valid primary keys.

We do not write custom password hashing algorithms or complex permission matrices. We use standard session cookies and a single role flag. Fine-grained permissions can wait until paying customers request them.

---

Day 4: The core endpoint and tests

Day four is dedicated to the application backend. We build the route that handles the primary mutation defined on day one.

We write two types of automated tests:

1. A happy-path test confirming that valid inputs create the database records and return a success response.
2. A rejection test confirming that invalid inputs (negative amounts, missing foreign keys, mismatched tenant identifiers) return clear error codes without leaving partial state.

The endpoint must return explicit error payloads following standard problem details. Generic internal server errors are not acceptable.

---

Day 5: The bare interactive surface

On day five, we build the interface. We intentionally skip design systems, animation libraries, and component frameworks.

A plain HTML form with clean styling is enough:

• An input for every required field
• Inline validation messages for missing or malformed inputs
• A submit button with a pending state to prevent duplicate submissions
• A confirmation view that displays the resulting database record

If the workflow feels confusing on a simple white page, adding drop shadows and gradient buttons will not fix the confusion. Plain interfaces expose confusing user experience immediately.

---

Day 6: Continuous deployment pipeline

Software running only on a developer’s laptop is unvalidated software. Local environments hide missing environment variables, filesystem differences, and network latency.

On day six, we connect the repository to continuous deployment. Every push to the main branch runs automated tests and updates a staging environment reachable over HTTPS.

We configure database connection pooling and SSL certificates on day six. Discovering deployment problems in week one gives the team three weeks to fix them calmly. Discovering deployment problems on day twenty-seven creates panic.

---

Day 7: The cold stranger test

On Friday afternoon, we send the staging URL to one person who was not involved in planning the product.

We provide only two pieces of context:

1. The URL and test login credentials.
2. The intended outcome: “Create one customer invoice and record a payment.”

We do not provide a call walkthrough or a setup document. We observe where they pause, which buttons they click, and where they encounter validation errors.

If the stranger finishes the task in four minutes, week one is successful. The foundation is sound. If the stranger gets stuck on step two, we know exactly what must be simplified before building secondary features in week two.

---

What to defer until week three or four

Protecting week one requires saying no to non-essential requests.

Here is the explicit cut list for the first seven days:

• Social logins (Google, GitHub, Apple). Use magic link or email and password.
• Custom notification preferences. Send transactional emails directly or skip until week three.
• Dark mode. Stick to a clean light theme.
• Export to Excel or CSV. Raw database access is sufficient for early founder testing.
• Billing integration. Stripe checkout can be wired in days fifteen to twenty-one.

Foundations decide whether an MVP lasts. By keeping week one focused on the single core transaction, founders save their capital and give their product a realistic chance of reaching paying users.

If you are planning an MVP and want experienced engineers to build your core workflow in twenty-eight days, review our Build Sprint timeline or book a technical discussion with our studio.