UbaidDev
How we work

Our software development process, from first conversation to source-code handover

Six stages, each with a review point you control. Scope is fixed in writing before anyone writes code, payments follow milestones you have signed off, and the repository is yours at the end.

Get Project EstimateDiscuss Your Project
  • 19 sections, nothing behind a form
  • Indicative timelines by project shape
  • What is billed, and what never is
  • The risks, published

The commercial path

Scope first. Pay after approval.

Free to scope
  1. 1
    Share your requirementsToday · free

    Guided questions and a live estimate range

  2. 2
    Approve a fixed proposalNo obligation

    Deliverables, exclusions, schedule and final price

  3. 3
    Kickoff paymentAfter approval

    Delivery slot reserved, build begins

  4. 4
    Review, handover, balanceAt delivery

    Repository, documentation and walkthrough

What is on this page

Five chapters, in the order buyers actually ask

This page is long because the questions are real. Jump straight to the chapter you came for, or read it top to bottom as one continuous explanation of how a project runs.

01

The process, end to end

The six stages, what happens inside each one, how long they usually run and how the first week actually feels.

02

Who builds it, and what lands in your hands

The people on the project, a full project walked through stage by stage, and the complete inventory of what you end up holding.

03

Money, and what happens when things change

When an invoice exists and when it does not, what is never billed, what is billed separately, and how a mid-build change is priced.

04

Working together without friction

What we need from you, an honest readiness check, the channels we use, the quality practices we hold to and the risks we plan for.

05

Deciding whether this is right for you

How a custom build compares with the alternatives, including when you should not hire us, plus the vocabulary and the ways to begin.

Would rather skip the reading?

Everything below is also answerable in one conversation. Bring a half-formed idea and we will tell you honestly whether custom software is the right call.

Discuss Your Project

Chapter 01 · The shape of a project

Six stages, each ending in a decision you make

These are the same six stages shown on our homepage. Every stage closes with something you can review and approve, so you are never asked to fund the next step on trust alone.

  1. Stage 12–5 days

    Discover

    Understand goals & requirements

    Closes when: You confirm the summary reflects your business

  2. Stage 22–4 days

    Plan

    Scope, NDA & fixed quote

    Closes when: You approve the fixed scope in writing, or you do not

  3. Stage 31–3 weeks

    Design

    UI/UX and architecture

    Closes when: You sign off the screens build will target

  4. Stage 43–12+ weeks

    Develop

    Build in milestone sprints

    Closes when: You sign off each milestone on staging

  5. Stage 53–7 days

    Launch

    Deploy, test & handover

    Closes when: You pass acceptance review and confirm go-live

  6. Stage 630 days included

    Support

    30-day bug-fix included

    Closes when: You decide: run it yourself, retain us, or hand it on

Below, each stage is broken down four ways: what we do, what we need from you, what you hold at the end of it, and what it costs to skip.

Durations on this page are indicative planning ranges for a typical project of that shape. The dates that apply to you are the ones in your signed proposal.

Chapter 01 · Stage by stage

What actually happens at each stage

Most process pages only describe the agency's side. Yours matters just as much, so both are listed here along with the deliverable that closes each stage and the honest cost of skipping it.

Stage 01

Discover

2–5 days

Understand the business problem and who the system is for, before anyone writes code.

What we do

  • Ask how the work happens today and where it breaks down
  • Identify the user roles the system has to serve
  • List the integrations and data you already hold
  • Raise risks, unknowns and dependencies early
  • Separate what must exist at launch from what can wait

What you do

  • Walk us through your current process, tools and spreadsheets
  • Tell us which outcome matters most first
  • Name the person who can approve decisions
  • Share the constraints you already know about

What you get: A written summary of goals, user roles, must-have features and the open questions still to settle.

Cost of skipping it: Skip it and the build solves the feature you asked for instead of the problem underneath it. That mismatch usually surfaces at launch, which is the most expensive place to find it.

Stage one. This is where every project starts.Next: Plan
Stage 02

Plan

2–4 days

Turn discovery notes into a fixed, written scope you can approve, change or walk away from.

What we do

  • Split the work into milestones with review points
  • Choose the architecture, stack and hosting approach
  • Price the scope and state what is deliberately excluded
  • Flag anything that needs your accounts or third-party approval
  • Sign an NDA first if you would prefer one

What you do

  • Read the proposal and challenge anything unclear
  • Confirm the budget range and the start you want
  • Cut scope now if the number is higher than you planned
  • Approve the scope in writing before work begins

What you get: A fixed-scope proposal: deliverables, milestone schedule, price, review points and explicit exclusions.

Cost of skipping it: Without a written exclusions list, every later disagreement becomes a memory contest. The exclusions are the part of the proposal worth reading twice.

Back to DiscoverNext: Design
Stage 03

Design

1–3 weeks

Agree what the system looks like and how it flows, while changes are still cheap.

What we do

  • Map the screens and the journey through each user role
  • Design responsive layouts for phone, tablet and desktop
  • Align typography, colour and components with your brand
  • Prepare a clickable prototype where a flow needs proving
  • Design the empty, loading and error states, not just the happy path

What you do

  • Review the screens against how your team actually works
  • Put one or two real end users in front of the prototype
  • Consolidate feedback into one round per screen set
  • Approve the design so build can start on a settled target

What you get: Approved screen designs, the component direction and a prototype of the flows you signed off.

Cost of skipping it: Moving a button in a design file costs minutes. Moving it after the build costs a re-test of everything attached to it. This is the cheapest stage to change your mind in.

Back to PlanNext: Develop
Stage 04

Develop

3–12+ weeks, by scope

Build the approved scope in reviewable milestones instead of one long silence.

What we do

  • Build the interface, APIs and database milestone by milestone
  • Prove risky integrations in the earliest milestone that touches them
  • Review code before it merges into the main branch
  • Deploy every milestone to a staging environment you can open
  • Keep a change log of what shipped in each milestone

What you do

  • Open the staging link and test it with real scenarios
  • Use your own awkward, real-world data, not neat sample data
  • Report issues in the shared project channel
  • Sign off the milestone so the next one can begin

What you get: A staging environment that grows every milestone, plus a change log you can check progress against.

Cost of skipping it: If nobody tests a milestone, its issues do not disappear, they just arrive later stacked on top of three more milestones of work built over them.

Back to DesignNext: Launch
Stage 05

Launch

3–7 days

Move the accepted build into infrastructure you own and control.

What we do

  • Deploy into your cloud account, under your billing and credentials
  • Run cross-browser and device checks before go-live
  • Configure domain, SSL, analytics and search console
  • Hand over the repository, credentials and environment notes
  • Walk you through the codebase, environments and deployment

What you do

  • Provide domain, DNS and the account access we need
  • Run your acceptance review against the agreed scope
  • Bring whoever will maintain it to the handover walkthrough
  • Confirm go-live once the review passes

What you get: A live system in your own infrastructure, the transferred repository, written documentation and a handover walkthrough.

Cost of skipping it: A launch without a real acceptance review just moves the review to your customers. Do the pass while there is still a milestone open to fix things in.

Back to DevelopNext: Support
Stage 06

Support

30 days included

Keep the system steady after launch and leave you able to run it without us.

What we do

  • Fix reported bugs inside the included 30-day post-launch window
  • Answer handover questions from your team or your next developer
  • Quote new features separately so nothing is bundled quietly
  • Offer an optional monthly maintenance retainer if you want one

What you do

  • Report bugs with the steps needed to reproduce them
  • Put real users on it early in the window, not on day 29
  • Decide whether to run it in-house or keep us on retainer

What you get: 30 days of included post-launch bug fixing and a documented path for whoever maintains it next.

Cost of skipping it: The included window is most useful in its first fortnight, while the people who built the system still have it loaded in their heads.

Back to LaunchNext: everything you receive

Chapter 01 · Timeline

How long it takes, and what actually moves the date

Nobody can quote a schedule from a page, so here is the honest version: three common project shapes, the indicative range for each, and the six things that move those ranges in practice.

Fixed-scope starter website

about 1–2 weeks end to end

A defined page set, your content, no custom back office.

  • Discover + Plan20%
  • Design25%
  • Develop35%
  • Launch20%

Business system or internal tool

about 6–10 weeks end to end

Two to four user roles, one or two integrations, real workflow logic.

  • Discover + Plan12%
  • Design20%
  • Develop58%
  • Launch10%

Multi-role platform or marketplace

about 12–20+ weeks end to end

Several dashboards, payments, notifications, permissions and reporting.

  • Discover + Plan10%
  • Design18%
  • Develop64%
  • Launch8%

What moves the date

How fast reviews come back

A milestone cannot close without sign-off. Review turnaround is the single biggest variable we do not control.

Whether the content exists

Copy, product data, images and pricing. Real content changes layout decisions, so late content means rework.

Number of user roles

Each distinct role adds screens, permissions and its own test pass. Two roles is not twice one role, it is closer to three.

Integrations and their owners

A payment gateway, an ERP export or a courier API can each involve approvals and credentials on someone else’s timeline.

Data you are bringing with you

Migrating messy historical data is its own piece of work. Clean data moves in days, inconsistent data takes longer.

Compliance or legal review

If your industry needs a review before go-live, that window belongs on the plan from day one, not at the end.

Percentages describe how a project of that shape usually splits across stages, not a commitment to a date. Want a real timeline? Size it with the estimator or send your requirements.

Chapter 01 · Momentum

Your first seven days, day by day

From the moment a brief lands to the moment you hold a fixed-scope proposal. This is how the first week runs when both sides answer promptly, and none of it costs you anything.

  1. Day 0

    You send the brief

    Your move

    A form, an email or a voice note. A rough idea is enough. Nothing is charged and no account is needed.

  2. Day 1

    Discovery conversation

    Together

    A call to understand the business, not to pitch. You leave with our honest read on whether custom software is even the right answer.

  3. Day 2

    Process and roles mapped

    Our work

    We write down how the work happens today, which roles the system serves, and the questions still open.

  4. Day 3

    Architecture and milestone split

    Our work

    Stack, hosting approach and the milestone breakdown, with the risky parts pulled early in the sequence.

  5. Day 4

    Fixed-scope proposal drafted

    Our work

    Deliverables, exclusions, milestone schedule and price. The exclusions list is written to be argued with.

  6. Day 5

    Proposal walkthrough

    Together

    We read it with you line by line. Scope gets cut here if the number is above your range. Cutting now is normal.

  7. Day 6–7

    Your decision window

    Your move

    Approve it, adjust it, or walk away owing nothing. The first payment only exists after a written approval.

Everything in that week happens before any money changes hands. If the proposal is not right, the correct outcome is that you decline it, and you owe nothing for the work that produced it.

Chapter 02 · The people

Who you actually work with

Roles rather than headcount, because that is the honest description. These are the jobs every project needs done and the stages they belong to.

Your direct contact

All six stages

The person writing your code is the person you talk to. There is no account manager relaying messages into the build.

Product and scoping

Discover, Plan

Turns your process into user roles, milestones and an exclusions list you can approve.

UI/UX design

Design

Screens, flows, responsive behaviour and the states most designs forget: empty, loading and error.

Application build

Develop

Interface, APIs, database and business logic, shipped milestone by milestone to staging.

Integrations

Develop

Payments, email, messaging, storage, and whatever internal system has to keep working alongside the new one.

Review and testing

Develop, Launch

Code review before merge, plus cross-browser and device passes before go-live.

Deployment and handover

Launch, Support

Your cloud account, your credentials, documented setup, and the walkthrough that closes the engagement.

On a smaller build one person covers several of these roles. We would rather say that plainly than imply a large team you will never meet. What does not change is the single point of contact: the person answering you is the person building it.

Chapter 02 · Worked example

One project, walked through all six stages

Process descriptions stay abstract until you see one applied. Here is a recognisable business problem moving through the six stages, including the part where the plan met reality.

Illustrative example. Written to show the mechanics of the process on a realistic problem. It does not describe a specific client engagement and claims no result on anyone's behalf.

The brief that arrived

A regional distributor with four depots. Orders arrive by phone and WhatsApp, stock lives in three spreadsheets that never agree, and invoices are typed by hand. The request that came in was "we need an app".

01Discover

What surfaced: The real problem was not order taking, it was that no two depots agreed on stock. Two roles mattered first: the depot manager and the travelling sales rep.

What that changed: Fix one source of truth for stock before touching anything else.

02Plan

What surfaced: Four milestones: stock ledger, order capture, invoicing, then dashboards and permissions.

What that changed: Accounting-software sync was explicitly excluded and written into the exclusions list as a later phase, which kept the first price honest.

03Design

What surfaced: Reps take orders standing in a shop, holding a phone in one hand.

What that changed: Order capture designed thumb-first for a phone, with the desktop layout treated as the secondary case rather than the primary one.

04Develop

What surfaced: Milestone one on staging surfaced duplicate depot codes in the historical data, invisible while it lived in spreadsheets.

What that changed: A data cleanup task was raised as a written change request with its cost and schedule impact stated, then approved before anyone started it.

05Launch

What surfaced: Switching four depots on one morning was the riskiest possible move.

What that changed: Two depots ran the new system alongside their spreadsheets for a week, then the other two followed once the counts matched.

06Support

What surfaced: Two defects reported in the first fortnight of the included window.

What that changed: Both fixed inside the 30 days. Their own team took ownership using the runbook, with a paid retainer declined and no penalty for declining it.

Want to see finished systems instead of a narrative? Browse what we have delivered or the ready-built products you can start from.

Chapter 02 · Deliverables

Everything you receive, listed once

Not a summary. This is the full inventory of what a normal project hands over, which stage it arrives in, and why each item matters to whoever runs the system after us.

Project deliverables, the stage each one arrives in, its format, and why it matters.
DeliverableStageFormWhy it matters
Discovery summaryDiscoverWritten documentThe shared record of goals, roles and open questions the proposal is built from.
NDA, if you want onePlanSigned agreementAvailable before the requirements conversation, not only after you commit.
Fixed-scope proposalPlanWritten documentDeliverables, exclusions, milestones and price. Any invoice traces back to this.
Milestone schedulePlanWritten documentWhat closes when, and which payment each closure is tied to.
Screen designsDesignDesign files and shared linksThe approved visual target for the build, per role and per breakpoint.
Clickable prototypeDesignShared linkLets you and your users walk a flow before it is expensive to change.
Staging environmentDevelopPrivate URLYou verify working software each milestone rather than reading a progress report.
Milestone change logDevelopWritten logWhat shipped, what changed and what was deferred, milestone by milestone.
Source code repositoryLaunchGit repository transferThe complete codebase, with history, transferred to your account.
Environment and config notesLaunchWritten documentEvery variable and service the system needs in order to run somewhere else.
Setup and deployment guideLaunchWritten documentHow to install, configure and deploy it without asking us.
Access and credential inventoryLaunchWritten listEvery account the system touches, held by you, revocable by you.
Handover walkthroughLaunchLive sessionA guided pass through the codebase, environments and deployment with your maintainer present.
Post-launch bug-fix windowSupport30 days, includedReported defects in delivered scope are fixed without a new invoice.

Documentation is written during the build rather than assembled afterwards, which is the only way it stays accurate. The terms behind these deliverables are set out in the terms, and the ownership model is unpacked directly below.

Ownership Model

Your software. Your cloud. Your code.

You end the engagement holding everything needed to run, change and host the system without us. These are the terms we work to on every project.

Full Source-Code Ownership

The complete repository transfers to you on final delivery. Nothing is licensed back to you to keep using it.

Client-Controlled Infrastructure

We deploy into your cloud account, under your billing and your credentials. You can revoke our access at any point.

Milestone-Based Delivery

Scope is split into agreed milestones. Each one is reviewed and signed off before the next begins.

Portable Architecture

Mainstream, open frameworks and standard data stores, so another team can take the codebase forward without a rewrite.

Clear Technical Handover

A live walkthrough of the codebase, environments, credentials and deployment process before we close the engagement.

Documentation

Setup steps, environment variables, integration notes and operational runbooks written as part of delivery, not after it.

No Artificial Vendor Lock-In

No proprietary wrappers, hidden dependencies or licence keys designed to make leaving us expensive.

Want these terms in writing?

We put ownership, handover and milestones into the proposal before any work starts.

Discuss Your Project

Each point above is a term of engagement we set and control, not a third-party certification.

Chapter 03 · Money, in plain terms

When payment is due, and when it is not

The order matters here: you see a price, you approve it in writing, and only then does anything become payable.

Scoping and estimates are free

You can configure a scope and see an estimate range without an account, a deposit or a card. Nothing is charged while you are still deciding.

No invoice before written approval

The estimate is a range, not a bill. An invoice only exists after you approve a written fixed-scope proposal that lists deliverables and exclusions.

Billing follows milestones

Payments are tied to milestones, and each milestone is reviewed and signed off before the next begins. The guided estimator previews 30% kickoff for orders of $2,000 or more, and 50% below $2,000, with the balance at handover; your signed proposal states the exact schedule and amounts.

Handover is part of the final milestone

Repository transfer, documentation and the technical walkthrough belong to final delivery. Invoicing is in USD or INR, the two currencies we bill in.

The order of events, start to finish

  1. 1Free

    Estimate range

    Before anything is agreed

    A range from the options you pick. No account, no card, no obligation.

  2. 2Free

    Fixed-scope proposal

    After discovery

    One firm price, an exclusions list, and a milestone schedule to approve or decline.

  3. 3First invoice

    Kickoff payment

    After you approve in writing

    30% for orders of $2,000 or more; 50% below $2,000. Starter websites are paid in full.

  4. 4Per the schedule

    Milestone reviews

    Throughout the build

    Each milestone is signed off on staging before the next one starts.

  5. 5Final invoice

    Handover balance

    At final delivery

    Paid against repository transfer, documentation and the walkthrough.

Never billed

  • The discovery conversation
  • The estimate range and the guided scope builder
  • Proposal revisions before you approve it
  • Reducing scope to fit your budget before signing
  • Bugs in delivered scope inside the 30-day window
  • The handover walkthrough and documentation

Billed separately, and named up front

  • Features added after the scope is approved, quoted as a change request
  • Your cloud hosting, billed by your provider to your account
  • Third-party subscriptions, paid APIs and licence fees
  • Domain registration and paid SSL, if you want one beyond the free option
  • Content writing, photography or paid stock assets
  • Optional monthly maintenance after the included window ends

The milestone schedule and payment terms that apply to your project are the ones written into your signed proposal. The full contractual wording, including invoicing windows and taxes, is on our terms page, with cancellation handling on the refund policy.

Chapter 03 · Change control

What happens when you want something different mid-build

Requirements change. That is normal and not a problem in itself. The problem is a change absorbed silently until the schedule slips or the invoice grows, so every change takes the same four steps.

  1. 1

    You raise it

    In the project channel, in writing, at any point. Asking what something would cost is free and does not commit you.

  2. 2

    We size it

    You get the effect on scope, price and schedule in writing, before a line of it is built.

  3. 3

    You approve, park or drop it

    Parking a change is a normal outcome. So is trading it against something already in scope.

  4. 4

    It joins a milestone

    Approved changes are attached to a milestone and recorded in the change log, so the final invoice matches a document, not a memory.

Usually costs nothing

Because the work has not been built yet.

  • Copy, labels and wording anywhere before launch
  • Colour, spacing and imagery before the build of that screen starts
  • Adding a field to a form in a milestone that has not started
  • Reordering screens or menu items
  • Swapping an icon, logo or brand asset

Always has a price

Quoted in writing before anyone starts it.

  • A new user role, which brings its own screens, permissions and test pass
  • A new integration, especially one with credentials or approvals attached
  • Changing the data model after real data is already in the system
  • Redesigning a screen set that has already been signed off and built
  • Adding payments, notifications or reporting that were listed as exclusions

Asking what a change would cost is always free, and reducing scope is a valid change request too.

Chapter 04 · Your side of the work

What we need from you to keep a project moving

Projects rarely slip because of code. They slip waiting on a decision, a login or a file. Six things prevent almost all of it.

One person who can decide

Reviews stall when nobody is authorised to approve. Name a single decision-maker for sign-offs.

Content and assets

Logo, brand files, copy, images, product or pricing data. Placeholder content is fine to start, but real content changes layout decisions.

Access where we integrate

Accounts for the payment gateway, email, domain, analytics or any third-party tool the build has to talk to.

Feedback in one round

Collect your team’s comments into a single consolidated round per review. Scattered feedback across days is the most common cause of drift.

Real test scenarios

The awkward order, the customer with two addresses, the refund nobody documented. Real edge cases found on staging are cheap.

Whoever owns it next

Bring the person who will run the system after launch to the handover. Documentation is good; documentation plus a walkthrough is better.

Chapter 04 · Honest self-check

Are you ready to start, or ready to talk?

There is a real difference, and picking the wrong one wastes your time. Tick what is already true and this will tell you which entry point actually suits you, including when the answer is not yet.

Tick everything that is already true
Your readiness0/8

Start with a conversation, not a form

Enough of this is still open that a scope built today would need rewriting next week. A discovery call is the cheaper first move, and it costs nothing.

Discuss Your Project

Nothing on this checklist is sent anywhere. It runs in your browser and resets when you leave.

Chapter 04 · Working together

How you reach us while the build runs

You talk to the person writing the code. There is no account manager relaying messages between you and the build.

WhatsApp & email

Day-to-day questions and updates, including audio notes when typing is slower.

Google Meet

Discovery call at the start and a walkthrough at each milestone review.

Dedicated Slack or Discord channel

One place for the project: links, staging URLs, issues and decisions.

Calls and calendar bookings

For decisions that are faster spoken than written.

The rhythm, not just the tools

You talk to the builder

Questions go to the person writing the code, not into a ticket queue to be triaged and relayed.

Every milestone has a walkthrough

A staging link plus a live pass through what changed, so sign-off is based on software you have used.

Decisions get written back

Anything agreed on a call is posted into the project channel, so no decision exists only in somebody’s memory.

One channel, not five

We ask you to keep project talk in the project channel. Scattered DMs are how requirements get lost.

Chapter 04 · How quality is kept

Commitments we can actually hold ourselves to

Deliberately specific rather than absolute. These are practices and terms we control on every project, not certifications or performance guarantees.

Code reviewed before merge

Changes are read and reviewed before they land on the main branch.

Cross-browser and device checks

Layout and flows are checked on phone, tablet and desktop widths before go-live.

A staging URL every milestone

You verify working software yourself instead of relying on a status report.

Documentation as part of delivery

Setup steps, environment variables and integration notes are written during the build, not after it.

Accessibility basics built in

Semantic markup, keyboard-reachable controls, visible focus and readable contrast. A practice, not a compliance certificate.

Security basics built in

Validated input, parameterised queries, secrets in environment variables, and dependencies updated at delivery.

30-day post-launch bug fixing

Included after launch. Reported defects in delivered scope are fixed inside that window.

Written sign-off at each milestone

Nothing moves forward on a verbal maybe, which keeps scope arguments out of the final invoice.

Each point is a practice we set and control, not a third-party certification, an uptime figure or a delivery-speed guarantee. The stack we build on is documented separately.

Chapter 04 · Risk register

What usually goes wrong, and the plan for each

Published on purpose. Every buyer has been burned by at least one of these, and naming them with a handling plan is more useful than claiming they cannot happen here.

The risk

The scope grows mid-build

Why it happens

Real usage always suggests improvements. The danger is absorbing them silently until the schedule quietly slips.

How we handle it

Every addition becomes a written change request with its price and schedule impact stated before it is built. You can approve it, park it, or trade it against something in scope.

The risk

Content never arrives

Why it happens

Copy, product data and images are usually owned by whoever is already busiest.

How we handle it

The milestone plan carries a content deadline. We build against placeholders to keep moving, and flag in writing when late content is what is holding the date.

The risk

Feedback trickles in over days

Why it happens

Several stakeholders reviewing at different times, each adding a comment.

How we handle it

One consolidated round per review, from your named decision-maker. The milestone stays open until sign-off, and the schedule moves with it rather than pretending it did not.

The risk

An integration behaves differently than documented

Why it happens

Gateways, ERPs and courier APIs have undocumented edges and their own approval processes.

How we handle it

Risky integrations are proven in the earliest milestone that touches them, not left for the final week when there is no room to react.

The risk

The budget is smaller than the scope

Why it happens

Ambition and budget are set by different conversations.

How we handle it

Scope is cut to fit before signing, in the open. We would rather deliver a smaller first phase properly than stretch a full one thin.

The risk

You need to pause the project

Why it happens

Funding, seasonality, a change of priority. It happens.

How we handle it

Milestone boundaries are the natural pause point. Work already signed off is delivered and transferable, so a pause does not become a write-off.

The risk

You want to leave, or we become unavailable

Why it happens

The fear behind every outsourcing decision, and a fair one.

How we handle it

Repository, documentation and credentials sit with you from launch, on a mainstream portable stack with no licence keys, so another team can pick it up without a rewrite.

Chapter 05 · Deciding

Four ways to get software built, compared fairly

A custom build is not automatically the right answer. Three of these four options are not us, and each one is genuinely better than us in the situation described.

Template or no-code platform

Best when
Validating an idea, or a standard process that genuinely fits the template.
Watch out for
Limits appear the moment your process differs from the template, and the platform owns the ceiling.
What you own
You rent it. Export options vary and are worth checking before you build on it.

Marketplace freelancer

Best when
Small, tightly specified, self-contained tasks with a clear finish line.
Watch out for
The lowest bid often skips documentation and handover, which is exactly what you need when the freelancer moves on.
What you own
Usually yes, but check what you actually receive: code without setup notes is expensive to inherit.

In-house hire

Best when
Software is your core product and you need daily iteration for years, not a delivery.
Watch out for
Slowest and most expensive way to start, and a single hire carries all the knowledge.
What you own
Yes, entirely. You also own recruitment, salary, tooling and cover when they leave.

Custom build with a delivery partner

What we do
Best when
A real business process that no product fits, where you want the asset at the end.
Watch out for
Needs your time in reviews and one person empowered to decide. Without those, any partner slips.
What you own
Yes. Repository, documentation and infrastructure are in your name at handover.

When you should not hire us

Said here rather than three milestones into a project neither of us should have started.

  • An off-the-shelf product already does the job for a monthly fee. We will say so.
  • You need a product changing every day, indefinitely. That is a hire, not a delivery.
  • Nobody on your side can commit to reviews and sign-offs. The process depends on it.
  • The budget only covers half the scope and the scope cannot be cut. Half a system helps nobody.

Chapter 05 · After the engagement

Life after handover: three paths, all supported

The end of a project should not be the start of a dependency. Whichever of these you choose, the repository, the documentation and the infrastructure are already in your name.

Run it yourself

The default, and the one the documentation is written for. Your cloud, your repository, your credentials, with a setup guide and a runbook covering the operational tasks.

No ongoing fee to us

Keep us on a retainer

An optional monthly arrangement for maintenance, dependency updates and small changes. Quoted separately, cancellable, and never a condition of handover.

Optional monthly

Hand it to another team

A supported outcome, not a penalty. Mainstream frameworks, standard data stores, documented setup and no proprietary wrappers, so a new team can read it and continue.

No exit fee, no licence keys

New features later are treated as their own small project: the same six stages, compressed, quoted separately, and never bundled into a maintenance invoice without you seeing the scope first.

Chapter 05 · Vocabulary

Plain-English glossary

These are the words that get nodded along to on calls, which is exactly how misunderstandings survive all the way to launch. Here is what each one means, without the jargon.

Scope
The exact list of what will be built, and just as importantly what will not. The exclusions half is the part that prevents arguments later.
Milestone
A reviewable chunk of the build with its own deliverable, its own sign-off and usually its own payment.
Staging environment
A private, working copy of your system on the internet, for you to test before anything is public. Break it freely.
Production
The live system your real users touch, holding real data.
Repository (repo)
The store holding your source code and its full change history. At handover it transfers to your account.
Source-code handover
You receive the complete code, not a licence to use a hosted copy of it. Nothing is rented back to you.
API
The doorway one system uses to ask another for data or actions. How your site talks to a payment gateway or your ERP.
Integration
Connecting your new system to something that already exists, so data stops being retyped between them.
Environment variables
Configuration and secrets kept outside the code, so keys are never committed into the repository.
DNS
The address book pointing your domain at your server. Changes can take a little while to spread worldwide.
SSL certificate
What turns a site into HTTPS and puts the padlock in the browser. Encrypts traffic between the user and the server.
Acceptance review
Your formal pass through the build against the agreed scope, before you confirm go-live.
Change request
A written record of something new you want, with its price and schedule impact, approved before it is built.
Runbook
The plain-language operating manual: routine tasks, backups, and what to check when something looks wrong.
Technical debt
Shortcuts taken to ship faster that make the next change harder. Sometimes a reasonable trade, always worth naming out loud.

Chapter 05 · Pick your entry point

Four ways to start, depending on how far along you are

You do not need a finished specification to begin. Choose the route that matches what you know today.

Guided scope builder

You know roughly what you need

Answer service-specific questions and get a live estimate range with a transparent breakdown of what drives the price.

Build a Similar System
Fast estimate

You want a number first

Use the quick calculator to size a budget by modules, integrations and timeline before you commit to a full brief.

Get Project Estimate
Fixed starter scope

You need a simple website now

A fixed starter scope with defined pages and deliverables, priced up front, when a full custom build is more than you need.

Order Website
Talk to a developer

You would rather talk it through

Bring a half-formed idea to a conversation. We will tell you honestly whether custom software is the right answer.

Discuss Your Project

Not sure which service you need? Browse services, solutions by outcome, work by industry, the stack we build on or systems we have already delivered.

Chapter 05 · Before you commit

Questions buyers ask about this process

Fifteen answers, including the ones that are awkward for us. If your question is not here, it is a fair thing to open a conversation with.

Do I have to pay anything to get a scope and an estimate?

No. Configuring a scope and receiving an estimate range costs nothing, and you do not need an account or a card. The first payment only becomes due after you approve a written fixed-scope proposal.

Is the estimate the final price?

No. The estimate is a preliminary range based on the options you selected. The fixed price is set in the written proposal after discovery, once the deliverables and exclusions are agreed. That proposal is what any invoice is based on.

How long will my project take?

It depends on shape rather than on a standard number. As an indicative planning range, a fixed-scope starter website is usually about one to two weeks, a business system or internal tool about six to ten weeks, and a multi-role platform twelve to twenty weeks or more. Review turnaround, content readiness, the number of user roles and third-party approvals move those ranges most. Your signed proposal carries the dates that actually apply.

What happens if my requirements change mid-project?

Changes are handled as a written change request. We tell you the effect on price and schedule before anything is built, then the affected milestone is updated. Work already signed off is not silently reopened, and parking a change or trading it against existing scope are both normal outcomes.

How do I verify progress instead of taking your word for it?

Every milestone is deployed to a staging environment you can open and test yourself, alongside a change log of what shipped. Milestone sign-off is based on software you have used, not a percentage in a report.

Who owns the code and the infrastructure?

You do. We deploy into your cloud account under your credentials, and the complete repository transfers to you at final delivery. Nothing is licensed back to you in order to keep using what you paid for.

What if I want a different team to take over later?

That is a supported outcome, not a penalty. We build on mainstream open frameworks and standard data stores, document setup and integrations during delivery, and add no proprietary wrappers or licence keys designed to make leaving expensive.

Can I start with a small first phase instead of the whole thing?

Yes, and it is often the better move. Discovery separates what must exist at launch from what can wait, and the milestone structure means a first phase can be delivered, launched and used while later phases are quoted separately.

What if I only have an idea and no requirements document?

That is the normal starting point. Discovery exists to turn a description of how your business works into user roles, must-have features and a written summary. You do not need a specification before talking to us.

What happens if I need to pause the project?

Milestone boundaries are the natural pause point. Whatever has been signed off is delivered and transferable, so a pause does not turn into a write-off. Restarting begins with a short re-review of where the build stopped.

Can my own developer review the code while you build?

Yes. Your technical people are welcome in the repository and in milestone reviews, and we would rather have that scrutiny during the build than a surprise at handover.

Who pays for hosting and third-party services?

You do, directly. Cloud hosting is billed by your provider to your account, and paid APIs, subscriptions and licence fees stay in your name. That is what keeps the infrastructure genuinely yours and revocable by you.

Will you sign an NDA before we discuss the idea?

Yes. An NDA can be signed before discovery, at the planning stage, if you would prefer the requirements conversation covered in writing first.

What is included after launch?

A 30-day post-launch bug-fix window is included, covering reported defects in the delivered scope. Beyond that you can run the system yourself using the handover documentation, or keep us on an optional monthly maintenance retainer. New features are quoted separately.

When should I not hire you?

When an off-the-shelf product already does the job for a monthly fee, when you need a product changing daily and indefinitely, which is a hire rather than a delivery, or when nobody on your side can commit to reviews and sign-offs. We would rather say that in the first call than three milestones in.

More answers on pricing, taxes and support are on the FAQ page, and the delivery model for overseas clients is on international delivery.

Back to the page map

Start with a scope, not a commitment

Tell us what you are trying to build. You will get an estimate range first, then a written fixed-scope proposal to approve or decline.

Get Project Estimate