How Software Development Actually Works

Most founders have never watched software get built. So they expect a team, a three-month waterfall, and a surprise at launch. That's not how it works if you're doing it right.

I build software end to end, on my own, in short cycles. Here's what that process looks like, and why it's faster and less risky than the agency way.

The four phases

Every build I do goes through the same phases. It's not waterfall (three months of planning, three of building, three of testing). It's not agile (three-week sprints with ceremonies). It's focused: one person, clear scope, rapid feedback.

Phase 1: Discovery and scope

Before I write any code, we talk. This is the most important phase and most agencies skip it.

I need to understand:

• What problem are you solving? Not what you want built, but what users can't do today.
• Who's using it? What's their context? Are they in an office? At a desk? On the go? Using it daily or monthly?
• How does it fit your business? Will it replace manual work? Enable a new service? Save time? That determines whether it's worth building.
• What's out of scope? I list what won't be built so there are no surprises later.

This phase takes a few calls, sometimes a week. It ends with a clear plan: what gets built in the MVP, what comes later, and roughly how long it'll take.

Most of this conversation happens on a call or in writing. No 50-page design document. Brevity is the point.

Cost to you: time. Maybe a few hours. No fees.

Phase 2: Design

Once scope is locked, I design. The user can see sketches and flows before I write a line of code. This is when "actually, I want it different" is easy and cheap to do.

I design on screen, not on paper. You see it click and flow. You can say "that button should be here" or "users will hate that" long before it's built.

I don't do wireframes and hand off to a designer. I design what I'm going to build. It's fast and it's coherent because it's one person.

This phase takes a week, sometimes two.

When it ends: You've approved the design. We both agree what the product looks like and how it works.

Phase 3: Build

Now I write the code.

I don't disappear for three months and come back with something. I share progress every week. You see the interface take shape, the data flow, features coming online.

This is the longest phase. For a complex SaaS, it might be eight weeks. For an internal tool, three or four.

During this phase:

• Every week: You see progress. Early screens, the data entry form working, the reporting dashboard live.
• Every two weeks: We talk. You ask questions, suggest tweaks, I adjust.
• I use short feedback loops. Problems surface early, not at launch. If something feels wrong, we fix it before it's built into the architecture.

Not agile ceremony, just communication. No standups. No velocity estimates. Just: "here's what I did, here's what's next."

Phase 4: Testing, refinement, and launch

When the build is feature-complete, I test. Not just whether the buttons work, but whether it actually solves the problem.

I test for:

• Does it actually work? Try to use it like a real user would. Where do you get stuck?
• Is it fast? Does a page load in under two seconds? Does a save feel instant?
• Edge cases. What happens if the user puts in weird data? Leaves required fields blank? Tries something they shouldn't?
• Browser and device support. Does it work on the devices your users will use?

You do some of this testing too. Fresh eyes catch things I miss.

When it's solid, we launch. I'll usually soft-launch to your team or a test group first, get feedback, fix any issues, then go live to users.

Post-launch, I'm available for questions, bug fixes, and tweaks. The first two weeks usually surface small adjustments.

When it ends: Live users, working software, no more bugs than any new product has.

Timeline and cost

Timelines depend on scope. A focused internal tool: two to three months. A full SaaS product: four to six. An API integration: two weeks.

The biggest factor is scope creep. If you add features mid-build, timelines move. I'm clear about that from the start.

Cost is quoted upfront, based on scope. It's usually one number, not per-hour billing. I own the risk of the estimate. If I'm off, that's my problem, not yours. That incentivises me to be efficient.

Why this process works

No handoffs. Most agencies hand your project between a strategist, a designer, and developers. Messages get lost. Decisions get made without the full picture. I do it all, so the product stays coherent.

Short feedback loops. Problems come up when there's time to fix them, not at launch. You're involved weekly, not just at the end.

One person accountable. You know who to ask. No "let me check with the team." If something's not right, I know instantly. I own it.

Scope is locked. This isn't "unlimited iterations till you're happy." We agree what gets built. Changes after that are quoted separately. Stops gold-plating and endless tweaks.

You get the code. You own it. If I leave, you have the repository, the keys, and full control. No vendor lock-in.

What this process is not

This is not:

• Waterfall. I don't design everything, build everything, test everything in sequence. I iterate.
• Agile with sprints and ceremonies. I don't do two-week standups and velocity estimates. I do focused work.
• Continuous deployment. I don't push to production every day. I build to a release, test, then launch.
• Unlimited scope. You can't keep adding features and expect the same timeline. Scope is fixed; changes are quoted.

For your team

If your team is using the product, I'll usually work with one person as the main contact. They're embedded in the process, see progress, and feed back to the rest of the team.

For larger organisations, I'll do kicks-offs with stakeholders, but the build is faster and clearer if feedback comes through one person. Too many voices, too slow.

Post-launch support

The build doesn't end at launch. After it goes live, I'm available for:

• Bug fixes. Something's not working? I'll fix it.
• Small feature requests. Need a new report or a different button? Easy additions are free (within reason).
• Monitoring and uptime. The software is monitored. If something's down, I'll know and fix it.

Most clients keep me on retainer for a few months post-launch. Some transition to their own team. Some keep me long-term.