How we work
How we deliver software projects
What happens between the first conversation and a system running in production — written for the person who has to sign off on it.
one call, no deck required
What this page covers
This page walks through what happens between the first conversation and a system running in production. It's written for the person who has to sign off on the project and wants to know what they're committing to. The process isn't a rigid template, but the stages below are the ones that matter on almost every web or mobile build we take on.
Starting point
Discovery and scoping
scope first, tools later
We start by understanding the problem, not by picking a technology. What does the system need to do, who uses it, what already exists, and what does success look like for this phase? We'll ask about the systems you run, the data you hold, and any constraints from your industry or your team.
The output is a scope you can read and react to: what's in the first release, what waits, and the technical approach behind it. For a Singapore SME replacing a manual process, that scope might be short. For an enterprise integration, it'll be longer and more detailed — more stakeholders to interview, more systems to trace, and more of the answer hidden in how the current process actually runs rather than how it's described on paper.
Agreeing the plan
Once the scope is clear, we agree on the plan: what gets built in what order, how we'll communicate, and how you'll review progress. We don't disappear into a six-month build and reappear with a surprise. The plan sets out the milestones, what you'll see at each one, and where your input is needed.
If your team has an existing project manager or a preferred tool, we'll work with it. The point is that you always know what's happening and what's next.
Milestones get named in the plan itself. For a customer portal that might be account access first and the transactional features second; for a mobile app, the core flow before the secondary screens. You review each one while changes are still cheap to make.
Design and technical approach
Before the build, we settle how the product will look and how it will be structured. That covers the user-facing screens and flows, and it covers the architecture underneath: data models, APIs, authentication, and how the pieces connect.
On mobile projects, this is also where the native-versus-cross-platform decision gets locked in, because it shapes everything downstream — how updates ship, how much of the device hardware you can reach, and what the team needs to maintain the app afterwards. We keep design and engineering in the same conversation, since a screen that looks good but can't be built cleanly costs everyone time. You'll see the approach before we start writing the main code.
What we decide before the build
The paths a real user takes through the product, including the empty states and the failure states.
What the system stores, what it reads from elsewhere, and which API integrations it depends on.
Who can see and change what, decided early because it reaches into every screen afterwards.
For mobile builds, the choice that shapes release speed, device access, and long-term maintenance.
Building in stages
We build in working increments rather than one big release at the end. That means you can see the product take shape, try it, and give feedback while changes are still cheap. Each increment adds a piece of real functionality, tested and connected to the rest.
How an increment typically lands
For a customer portal, that's often sign-in and the account view: enough that a real person can log in, see their own data, and tell us whether the shape is right.
Orders, bookings, submissions, payments — the features that carry the business weight and connect to outside services.
Settings, notifications, admin views, reporting. On mobile, the core flow ships before the secondary screens for the same reason.
order shifts when your priorities do — we replan together
Testing and quality checks
Testing runs alongside the build, not as a final gate. We test the logic, the integration points, and the flows a real user will follow, including the cases where something goes wrong. What we won't do is claim a system is flawless; we'll tell you what's been tested and what to watch.
we list what's tested, and what isn't
Rules, calculations, stored records and the states a record can be in — checked against the scope, not against a wish list.
If your app connects to a payment provider or a CRM, we test those connections against the actual behaviour, not just the happy path.
Real flows on real devices and real screen sizes, including the slow connection and the wrong input.
Given attention throughout the build, because retrofitting it later is harder and more expensive than designing it in.
Launch and release
Launch is a planned step, not an accident. We prepare the release, check the environment it's going into, and make sure the data and access are set up correctly.
We stay involved through the release itself, because that's when small issues surface and get fixed quickly — a redirect pointing at the old host, an environment variable set for staging, a mobile build that needs a fresh certificate.
We deploy, check the live environment, and stay present for the moment you move off the old process. Anything that surfaces in that window gets handled while the old path is still fresh in everyone's head.
Submission has its own review timeline, which is worth planning around rather than discovering late. We prepare the listing material and handle the back-and-forth if a reviewer asks for changes.
support is part of the plan, not an afterthought
Support after launch
A launch isn't the end of the work. Real users find real edge cases, and systems need maintenance as the platforms they run on change. We offer ongoing support so your application keeps working and can be extended as your needs shift.
That might mean fixing something that broke, adding a feature that's now clearly needed, or handling an update when a third-party API changes underneath you. The level of support depends on your project, and we'll agree it as part of the plan rather than leave it vague.
something stopped behaving
a feature now clearly needed
an API moved under your feet
What we need from you
Good projects are a partnership. We need someone on your side who can make decisions, answer questions about your business, and review the work as it appears. That's usually one or two people, not a committee.
Someone who can say yes or no without going away to ask. It's the single biggest factor in how fast a project moves.
How the process works today, what goes wrong with it, and who it affects. The details usually live with the people doing the work, not in a document.
Each increment needs a look before the next one builds on it. A short review keeps the queue clear; a long silence stops the line.
If your team has technical staff, we'll coordinate with them on integration and infrastructure. If you don't, we'll handle those decisions and explain them in plain language.
Questions we get before a project starts
How long does a project usually take?
It follows the scope, not a fixed number of weeks. A small web tool replacing a manual spreadsheet process is a different shape of project from a mobile app with payments and a back-office view. The plan we agree after scoping is where the real dates live, and each milestone gets its own review before the next begins.
What does the scoping conversation actually cost?
Your time. It's a working session about your process and your constraints, and you leave with a written scope you can read and react to. If the project isn't a fit for us, we'll say so rather than stretch the conversation.
Can you work with our existing systems?
That's most of the work we do. Existing databases, internal tools, payment providers and CRM systems all get traced during scoping, and any API integration gets tested against real behaviour rather than assumed. Where a system can't be reached cleanly, we'll tell you what the alternatives are before the build starts.
Who owns the code at the end?
You do. Handover is part of the plan rather than a negotiation at the end, and we'll walk your team through how the system is put together, where it's hosted, and what it depends on. Whether you continue with us or take it in-house is your call.
What happens if our requirements change mid-build?
They usually do, and building in increments is what makes that survivable. A change lands as a conversation about priority and sequence rather than a rewrite, because the pieces are already separated and tested. Where a change affects the plan, we'll say what it displaces.
Bring us the problem, not a finished brief.
we'll write the first scope with you
Where to go next
Prefer to ask first
Send a question about your project and we'll answer it plainly — no obligation to start anything. If it's easier to talk, the studio is reachable Monday to Friday, 9:00 AM to 6:00 PM.
replies come from the people who build