Skip to content
IntegrasiHub

Four stages. You can stop at the end of any of them.

No lock-in, no phase that only makes sense if you buy the next one. Here is what happens, what comes out of it, and what we need from you.

1

Scope

Nobody writes code until both sides can describe the same release.

Scoping is a paid piece of work in its own right, and it is deliberately small. We go through the product, the constraints you already know about, and the ones that turn up once someone technical looks properly. What comes out is a written description of the release specific enough to disagree with.

What comes out of it

  • A written scope: what ships, what it does, what is explicitly out
  • The technical constraints that will shape the build
  • A shape and a figure you can take to whoever approves budget
  • An honest read on whether this is worth building at all

Your part

A couple of working sessions and access to whoever knows the product best. That is it.

2

Design and build

Progress you can click, from the first week.

Interface design is done by the people who then build it, so nothing gets drawn that cannot ship. Work goes to a preview environment as it lands. You review the product rather than a document describing the product, which makes disagreements cheap and early instead of expensive and late.

What comes out of it

  • A preview URL, updated continuously
  • Interface design worked through against real content, not placeholder text
  • Working software in reviewable slices
  • A running note of decisions and why they were made

Your part

Open the preview and tell us when something is wrong. Earlier is cheaper.

3

Test and launch

Tested on the paths people actually use.

We test the routes your users take rather than chasing a coverage number that flatters the report. Accessibility and responsive behaviour are checked as part of this, not filed as a later improvement. Release goes out to infrastructure in your accounts.

What comes out of it

  • The release, live, in your own accounts
  • Accessibility and responsive behaviour verified, with the limits named
  • Analytics and error reporting wired up before launch, not after
  • A rollback path that has been tried

Your part

Approve the release and tell us who needs access to what.

4

Continue or hand over

Two good endings, and you pick.

Either we carry on against your roadmap, or we hand over properly and stop. Handover means the repository, the deployment setup, the environment configuration and a walkthrough with whoever holds it next. Everything lives in your accounts throughout, so there is nothing to extract.

What comes out of it

  • Repository, deployment and environment configuration, all yours
  • A recorded walkthrough with the engineer taking it on
  • Documentation written for whoever inherits it
  • A maintenance plan, if you want us to keep running it

Your part

Tell us which ending you want. You can change your mind later.

Four commitments you could hold us to.

Each one is specific enough that you would notice if we broke it.

  • One person owns the release

    A named person is accountable for what ships and when. If it is going to slip, you hear it from them before you notice it yourself.

  • Show the product, not a status report

    Work lands in a preview environment you can open. Progress is something you click through, which makes disagreements cheap and early.

  • Leave code your next engineer can read

    We assume someone else maintains this after us, because often that someone is us. It shapes the structure, the naming, and what we choose not to be clever about.

  • Say only what we can evidence

    We describe what we built and what it does. Where we hold no measured result, we say so rather than reach for a number that sounds good.

Start at stage one.

Scoping is small, paid, and yours to keep whether or not you carry on with us.

Start a projectCompare the engagements