Playbook 4 of 10, Build
Build and ship v1
Build the first release in short cycles, keep a release checklist, review against the cut line and put it in front of a small group.
What you will have at the end
- A working first release
- A release checklist
- Weekly review notes that show scope changes
- A short release note
- A backlog ordered by evidence
The steps
-
Set a weekly rhythm
Choose one goal for the week, write it where the whole team can see it, and review it at the end. A fixed rhythm makes slipping visible early, which is when it is cheapest to fix.
-
Build the riskiest path first
Build a thin working slice from the start of the path to the first result before you widen anything. If the hardest part does not work, you learn it in week one rather than week ten.
-
Keep a release checklist from the first week
List what must be true before anyone outside the team uses the product, including data protection basics, accessibility, backups and a way to see errors. Add to the list every time something surprises you.
-
Review against the cut line every week
Compare what was built with the written cut line. When scope changes, write down what changed, why, and what moved below the line to make room.
-
Release to a small group you can talk to
Start with a few people you know by name, so you can watch what they do and ask what they expected. Widen the group only when the first group can reach the result without help.
-
Write down what broke and what you learned
Keep a short release note and an ordered backlog that records the evidence behind each item. The next cycle starts from that backlog, not from memory.
The playbook at a glance
A cover, one public figure that frames the question this playbook answers, and the steps drawn as one path.
Show the figures as a table
| Years since opening | All private industries | Information, including software | Professional and technical services |
|---|---|---|---|
| 0 | 100% | 100% | 100% |
| 1 | 79.6% | 80.8% | 81.6% |
| 2 | 69.1% | 70% | 71.2% |
| 3 | 61.4% | 60.8% | 63% |
| 4 | 55.4% | 53.3% | 56% |
| 5 | 50.2% | 46.8% | 50.3% |
| 6 | 46.4% | 42.6% | 46.9% |
| 7 | 43.6% | 38.6% | 43.2% |
| 8 | 40.3% | 35.4% | 40% |
| 9 | 37.4% | 33% | 37.2% |
| 10 | 34.7% | 30% | 34.3% |
Establishments with at least one employee, opened in the year to March 2015. A closure is not always a failure: it includes sales and mergers.
Source: U.S. Bureau of Labor Statistics, Business Employment Dynamics, Table 7 , March 2025 release
These figures describe all new U.S. businesses, not WE's results.
The steps, in order
- Set a weekly rhythm
- Build the riskiest path first
- Keep a release checklist from the first week
- Review against the cut line every week
- Release to a small group you can talk to
- Write down what broke and what you learned
Open these next
- Security baseline checklist A year-one checklist written against public security standards.
- MVP cut-line worksheet A worksheet for sorting features above and below the line for version one.
- Decision log A running record of decisions, the reason for each and who made it.
- Team Composer Choose the roles your SaaS team needs and how many people each one needs, then carry the sketch to the application. No sign-up, no price.
What good looks like
A good first release is small, working and watched. The team can say what shipped this week, what moved below the cut line and why, and the people using it are people you can call.
- Each week ends with a written review that compares what was built with the cut line.
- A thin slice of the riskiest path worked early, so the hardest problem was found while it was still cheap.
- The release checklist exists, carries dates and has been followed at least once, including the security and accessibility items.
- A person outside your team reached the first result without you doing it for them.
- You can undo a release. The way back to the last good version was decided before the release, not during it.
Decision aid: ready to widen the release group
Before you move from a few named people to a wider group, answer each row. A row you cannot answer yet is the next piece of work.
| Check | Ready when | If not yet |
|---|---|---|
| The first result | A person outside the team reached it without help, and you watched. | Keep the group small. Write down where they hesitated and fix that first. |
| Errors | You can see an error as it happens and say who it affected. | Add error reporting before more people arrive. |
| Way back | You know how to return to the last good version and have done it once. | Practice the rollback on a test copy before the next release. |
| Security baseline | The checklist items are done or have a dated reason for waiting. | Work through the baseline checklist and date each deferral. |
| Accessibility | A keyboard-only run through the path to first value works. | Fix the keyboard path before adding visual polish. |
| Customer data | You know what the product stores, where, and who can see it. | Write the list down. Ask your counsel about anything you do not understand. |
| Backups | A restore has been tried, not only a backup taken. | Try a restore on a copy and write down what happened. |
Standards to build against
A checklist is stronger when each line points to a public standard instead of a habit. Two are worth putting on the first list.
The W3C’s Web Content Accessibility Guidelines (WCAG) 2.2 cover a wide range of recommendations for making web content more accessible, and the document is a W3C Recommendation dated 12 December 2024. Put its success criteria on the release checklist in the first week, because fixing accessibility after launch touches everything that is already built.
NIST’s Secure Software Development Framework, published as SP 800-218, describes a core set of high-level secure software development practices that can be integrated into each SDLC implementation. Use it as a vocabulary for the security items on your checklist, and write down which practices you have adopted and which you have deferred.
Neither document tells you that your product is accessible or secure. They give you a shared list to check against and to show to a reviewer.
Common mistakes
| Mistake | Why it costs you | Do this instead |
|---|---|---|
| Adding scope without writing it down | The cut line stops meaning anything and the release keeps moving. | Record every change to scope with the item that moved below the line. |
| Leaving security and accessibility until later | Retrofitting them touches everything that is already built. | Put both on the release checklist in week one and build them in as you go. |
| Releasing to everyone at once | You cannot watch or talk to everyone, so you learn little. | Start with a small group you can reach by name. |
| Having no way to roll back | A bad release becomes an outage you cannot undo. | Decide how you will return to the last good version before you release. |
| Measuring activity instead of results | A busy team can still be building the wrong thing. | Review each week against the result the customer came for. |
| Keeping decisions in chat | A remote team loses them within days and re-argues them. | Write each decision in one shared place with its date and reason. |
Evidence to check before you move on
Move to Hire your first team member when you can show each of these.
- A person outside your team reached the first result without you doing it for them.
- The release checklist exists, has dates on it and has been followed at least once.
- Weekly review notes show what changed in scope and why.
- The backlog is ordered, and each of the top items points to something you observed.
Version one will be incomplete. That is expected. What matters is that you can say exactly what is missing and what you saw that told you so.
Where WE can help
WE’s Product and IT Development line builds in short cycles, shows working software at the end of each one and builds secure development practice in from the first repository. It does not run your live service or offer round-the-clock support. The service line page sets out what it covers and what it does not.
Sources
The steps and the decision aid draw on the articles, research briefs and templates below. Each names the public sources it read.
- An operating rhythm for a remote offshore team
- Shipping safely with feature flags and rollback
- Estimating a first release: ranges and what they hide
- Security baseline for year one
- Accessibility at launch
- Security baseline checklist
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, read October 10, 2026
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218, read October 10, 2026
Start a readiness review
Tell WE where the company stands. WE replies to arrange a conversation and a written read of your company's timeline.
A short PDF of the charts and sources, sent by email to the address you give.
Talk to WE : A question that does not fit a form.