How we embraced AI: building software with Claude

Anthropic released Claude 3 Opus on 4 March 2024 (Anthropic, 4 March 2024). Since June 2024, every custom project that starts at Sedang Bahagia is built with Claude, and the 8-week build has become a 4-week sprint.

Claude shortens the build and leaves its steps in place. Requirements, the clickable prototype and its revision move from weeks 1–3 into week 1. The build moves from weeks 4–7 into weeks 2–3, with Claude drafting code, tests and documentation and two people reviewing every change: the engineer who opened the pull request, then the technical lead. The CI tests must pass before anything merges. Launch and handover keep a week of their own, and data access and scope decisions take as long as they always have.

The two plans, side by side:

How the sprint runs:

Week	What happens	What you receive
Week 1	Interviews, a look at the data, and a clickable prototype tried and revised with the people who will use it	A one-sentence problem statement, the prototype and a scope agreed against it
Weeks 2–3	The core features and integrations, built on your real data	A staging demo every week
Week 4	Production launch with the first users	The live product and the full handover

1. Until June 2024, three of the eight weeks came before the build

Before June 2024, every custom build we took on ran 8 weeks. How we run an 8-week custom software build, which we published in August 2022, walks through them week by week:

• Week 1: requirements, from interviews, the current process and access to the data.
• Week 2: a clickable prototype, tried by a handful of users.
• Week 3: revisions with the people who would use it, and a scope signed off against the screens.
• Weeks 4–7: the build, on the client’s real data, with a staging demo every week.
• Week 8: deployment, with the data moved in and the handover.

Two weeks of screens before the build made sense while a built screen was slow and expensive to change. A clickable prototype was quick to redraw, so it paid to settle the flow on linked pictures first. The home-visit midwife booking app we built in 2022 ran that way: requirements with the client’s operations team, then a clickable prototype of the mother app, the midwife app and the console, revised in week 3 before the build of all three started in week 4.

The plan rested on one assumption: typing the code was the slow part, so everything that could be settled before code should be. With Claude drafting the code, that part takes less time, and the plan has changed around it.

2. From June 2024, the same steps fit into four weeks

Requirements, a clickable prototype, its revision with users, a scope agreed against it, the build on real data, a weekly demo, the launch and the handover all stay in the plan. Most of them take less time:

• Weeks 1–3 become week 1. With Claude drafting the screens, the prototype that took week 2 is ready inside week 1, and the revision that took week 3 happens on it before the week is out. The scope is agreed against the prototype before the build starts.
• Weeks 4–7 become weeks 2–3. Claude drafts the code, tests and documentation that engineers used to type (section 3).
• Week 8 becomes week 4, with no time saved. Moving data in, training people and launching take the time they take.

Week 1 is the fullest week of the sprint. Interviews, a look at the data, the prototype and its revision all happen in the same five working days. The people on the client’s side need more time that week than in any other: to be interviewed, to grant access and to try the screens.

3. Claude drafts the change, and two people review it before it merges

An engineer decides what Claude drafts and whether it ships. The engineer breaks the work into tasks, gives Claude each task with the code around it, and reads what comes back. Claude drafts the screens, endpoints and database changes, the tests for that code, and the setup notes, module notes and pull request description that go with it. Architecture, scope, review and every conversation with the client stay with people.

A task goes from description to merge in six steps:

1. The engineer writes the task: what the change must do, which parts of the code it touches and which tests will prove it.
2. Claude drafts the change: the code, its tests and a description for the pull request.
3. The engineer reads and runs it, line by line, fixing what’s wrong and rewriting what’s unclear.
4. The engineer opens the pull request, with the description corrected to say what the change does.
5. The technical lead reviews it against the task, the rest of the product and the client’s scope.
6. CI runs every test, and the change merges only when they all pass.

The author knows what the task was meant to do, so they catch the draft that does something else. The technical lead knows the whole product, so they catch the change that’s right on its own and wrong next to everything else. The tests catch what both of them miss.

Anthropic released Claude 3.5 Sonnet on 20 June 2024, in the first weeks of the change (Anthropic’s announcement). The review rules don’t depend on which model drafts the code: the same two people read the same lines, and the same tests have to pass.

4. The tests decide what merges, so reviewers read them as closely as the code

Code that Claude drafts reads well whether or not it works. A wrong draft looks as finished as a right one, with the same formatting and the same tidy names. So every change carries tests, and CI runs them on every push: feature tests for each step of the workflow, unit tests for small pieces such as a price calculation or a date rule, and integration tests for the product working with its database, payments and messaging.

A test that Claude drafted is still a test someone has to read. It’s possible to write a test that passes because it checks nothing. Both reviewers ask one question of each test: would it fail if the feature it covers broke? They also check that the change does what the task said and nothing else, that its names and structure match the rest of the product, and that no keys, passwords or client data sit in the code or the tests.

Reading the tests this closely takes a little longer per change than trusting the draft, and uses up some of the time Claude saves on drafting. A mistake caught in review is fixed before anyone uses it, while the same mistake found by a user after launch is fixed in front of the client.

The tests also outlive the build. They go to the client with the code at handover, so whoever changes the product next can see at once whether something broke.

5. Client code and data reach Claude only through the Claude API on our company account

We use Claude through the Claude API, on our company account, under Anthropic’s Commercial Terms of Service. In those terms we are the “Customer”, what we send to Claude is “Prompts”, what comes back is “Outputs”, and the two together are “Customer Content”. The version effective 14 May 2024 (Anthropic’s Commercial Terms of Service) says about that content:

• On training: “Anthropic may not train models on Customer Content from paid Services.”
• On confidentiality: “Customer Content is Customer’s Confidential Information.”
• On ownership: “Anthropic agrees that Customer owns all Outputs”.

No client code, document or data goes through an engineer’s personal account, and we sign an NDA on request.

Ownership of the product stays with you. You own 100% of the source code from the first commit, whether Claude drafted a line or an engineer typed it. The repository is yours, with its full history, and the history shows every change, who reviewed it and which tests it passed.

6. Data access and scope decisions take as long as before

Data access takes as long as the person who approves it. Claude doesn’t speed up an approval. If access to the client’s data is approved before week 1, the build runs on real data from the start of week 2. If it isn’t, we build against placeholders shaped like the real data and swap them out the day access arrives. The work goes on, but the placeholders can hide what the real data would have shown, so a late approval still costs time at the end.

A faster build invites a longer feature list, so the scope rule stays as it was: one problem, agreed in week 1, and three questions for anything new.

1. Does it serve the one problem agreed in week 1?
2. Will the product be unusable on day one without it?
3. Is there a manual or CSV workaround for the first month?

A request joins the sprint only if the first two answers are yes. Everything else goes on the backlog with a rough size.

Decisions are the other half. A sprint moves only as fast as someone on the client’s side can make scope calls at each weekly demo, and Claude changes nothing about that. A large idea becomes a narrower first version, built as a minimum lovable product: one problem for one user group, with the rest of the idea on the backlog for the releases after it.

7. A handover includes the code, the documentation, admin access, a backlog and the product live

What you need at the end of week 4 is a product that’s live and that another team could take over. How much of the code Claude drafted doesn’t change what you receive.

Week 4 runs in the same order that week 8 did:

1. Data moves in: existing records, such as customers, products and open orders, come across from wherever they live.
2. The team learns it: each role is trained on its own screens, on the live product.
3. The first users go live: one team, site or group of customers first.
4. The first days are fixed: whatever real use turns up is fixed or added to the backlog.
5. The handover: everything below moves to your company’s accounts.

At handover you receive:

Item	What it means for you
Source code	In your repository, with full history. Ownership is 100% yours from the first commit.
Tests	The feature, unit and integration tests and the CI setup that runs them, in the same repository.
Documentation	How to run, deploy and change the product, written for the next developer.
Admin access	Credentials for hosting, databases, app store listings and third-party services, under your company’s accounts.
Backlog	The deferred features, each with a rough size and the reason it waited.

The documentation is drafted with the code, in the same pull requests, and reviewed with it. It describes the product as it is at handover, which can differ from what was planned in week 1.

The test of a handover is whether another team could pick up the product from the code, the tests and the documentation alone. Accounts are part of that test. A product whose hosting or app store listing sits under a vendor’s name is one you don’t fully control, so everything goes under your company’s accounts from the start. When a team inherits a product without these, taking over a stalled project starts by recovering them.

8. Takeaways

Claude shortens the build, and two reviews and the CI tests decide what merges. The engineer who opened the pull request reads every change first, then the technical lead, and nothing merges until the tests pass.

The prototype stays, in week 1. Requirements, the prototype and its revision share the first week, so the scope is agreed against screens the users have tried before the build starts in week 2.

Client code and data go to Claude only through the Claude API on our company account. The version of Anthropic’s Commercial Terms of Service effective 14 May 2024 says Anthropic may not train models on Customer Content from paid Services.

Arrange data access before week 1, and keep the scope to one problem. Claude speeds up neither, and both decide whether four weeks is enough.

Ask what you receive at the end. The code with its tests, the documentation, admin access under your accounts and a sized backlog are what let your own developers, another team or us carry on.

Every custom build that starts with us now runs as a 4-week sprint with Claude, for web apps and mobile apps alike. We are also building our own business systems, and we are looking at where Claude can help inside them. If you have a first version in mind, send the technical lead a short brief on the problem, the users and the data, and you’ll get a reply within 24 hours.