Ship in week one without creating a week-two rewrite

Shipping in week one is useful only when the release reduces uncertainty and makes the next release easier. A disposable demo may create movement, but it does not prove that the team can deliver through the real system. The better target is a narrow vertical slice: one meaningful user action, running through the intended interface, application logic, data path, and deployment process.

Define the slice by an outcome

A vertical slice is not a thin layer of every planned feature. It is the smallest complete path through the product that produces a result someone can judge.

For an appointment product, that might be choosing an available time and creating a booking. It is not a finished calendar, notification suite, administration area, and billing system. For an internal approval tool, it might be submitting one request and recording one decision, without advanced routing or reporting.

Write the slice as a testable sentence: “A user in this role can take this action and see this result.” Then name what the slice will not handle. Those exclusions prevent a one-week goal from quietly becoming a miniature version of the whole roadmap.

The slice should answer one important product question and one delivery question. The product question may be whether the interaction makes sense. The delivery question is whether the team can build, deploy, observe, and change it through the intended route.

Discover just enough to choose well

Focused discovery is not a compressed requirements phase. Its job is to identify the decision that would be expensive to reverse after implementation.

Before coding, establish:

• the user and situation the slice serves;
• the result that makes the interaction useful;
• the riskiest assumption in the flow;
• the minimum data the system must retain;
• constraints involving identity, permissions, payments, or sensitive information;
• the person who can accept or reject the demonstrated outcome.

A clickable prototype can settle interaction questions before they become code. It is particularly useful when the team needs to compare navigation, wording, or information order. But the prototype is an input to the slice, not the slice itself. It cannot reveal whether authentication works in a deployed environment, whether data survives a retry, or whether an external service behaves as expected.

Time-box discovery and prototype work around explicit decisions. If a prototype screen does not help the team choose, remove it from the week-one plan.

Build on the path you intend to keep

Speed becomes disposable engineering when the team creates a special route that cannot support the second increment. Common examples include hard-coded success responses, shared administrator accounts, untracked database edits, and manual deployments that only one developer understands.

Avoiding those shortcuts does not require designing the final architecture. It requires a small set of durable foundations:

• keep the code in version control;
• create the real build and deployment path;
• manage schema changes as repeatable migrations;
• separate configuration from source code;
• add basic error reporting and request visibility;
• cover the slice’s critical rule with an automated test;
• document how to deploy and reverse the change.

This aligns with the AWS Well-Architected guidance on small, reversible changes: smaller changes are easier to diagnose and reverse, particularly when supported by build, delivery, configuration, and change-management systems.

“Real” does not mean “built for every future scale.” A managed database, simple application boundary, and conventional deployment may be enough. The important distinction is that week two extends the path rather than replacing it.

Use real environments as part of the product test

A local demonstration proves that a developer can run the feature. A deployed slice tests a wider set of assumptions: configuration, permissions, migrations, integration credentials, network behavior, and recovery.

Create a production-like environment early, even if traffic and infrastructure are modest. Apply the same deployment mechanism that production will use. Seed only non-sensitive test data, make environment differences explicit, and verify the slice from outside the development machine.

An early production release can still have limited exposure. Restrict access to an internal group, a selected cohort, or a feature flag. Decide in advance what signal permits broader exposure and what condition triggers rollback. Google’s SRE guidance on canary releases explains why staged exposure matters: tests cannot reproduce every production condition, so a release should be evaluated on a limited population before wider rollout.

The principle applies even when formal canary infrastructure would be excessive. Small products can begin with controlled accounts, reversible flags, and a known-good prior deployment. The mechanism should match the risk, but “we can undo this” must describe an exercised path rather than an intention.

Make the weekly demo a decision point

A demo is valuable when it changes the plan. Show the slice from the deployed environment, using the same route available to its intended user. Do not hide incomplete states behind a narrated happy path.

Ask observers to decide three things:

1. Does the completed outcome solve the stated problem?
2. Which failure or edge case must be addressed before exposure grows?
3. What is the next smallest slice that extends this one?

Record decisions beside the demonstrated version. Feedback such as “make it more intuitive” is not ready for implementation; turn it into an observable issue tied to a user action.

This is how Alfcode’s product development process connects speed to continuity: focused discovery narrows the decision, a clickable prototype resolves interaction choices, and implementation moves through real environments into weekly demos and early releases. Alfcode treats those stages as one feedback loop, so the artifact shown this week becomes the base for next week’s work rather than a polished detour.

Set a week-two test before shipping

Before calling the first slice complete, choose one plausible next requirement and walk through how it would be added. You are not building it yet. You are checking whether today’s shortcuts have already made tomorrow unusually expensive.

Ask whether the next change can use the existing repository, data model, environment, deployment path, and monitoring. Then verify that the current release can be rolled back without improvisation. If either answer depends on replacing the slice, it is a prototype wearing production clothes.

The final test is simple: can the team ship one more useful behavior through the same path next week? If yes, the first release created both product evidence and delivery capacity. If no, reduce the slice or repair the path before calling speed a success.