Intactic
Start a project

Process

From first call to production.

Four phases, each with a written output. You can stop at the end of any of them and keep what was produced, including the architecture.

Frame

Understand the system as it is.

1–2 weeks

Workshops with the people who do the work, an audit of what already exists, and a written definition of success that both sides sign. This phase is where a project is usually saved.

What happens

  • Interviews with operators, not only sponsors
  • Audit of the current system, data and contracts
  • Constraints: regulatory, commercial, technical
  • Success measures that can be checked later
  • A written brief and a go or no-go decision

At the end

You get
A written brief
Your time
4–6 hours
Fee
Fixed

If we are not the right team for the problem, we say so here. It is cheaper for both of us than discovering it in month three.

Architect

Decide before building.

2–3 weeks

Domain model, integrations, interface direction, risk register and an estimate. The output is a document another team could build from, which is the test of whether it is finished.

What happens

  • Domain model and state transitions
  • Integration map with failure behaviour
  • Interface direction and two key screens
  • Risk register, ranked by cost of being wrong
  • A fixed-scope proposal with milestones

At the end

You get
An architecture pack
Your time
6–10 hours
Fee
Fixed, credited

Most disagreements surface here, while they are still cheap to settle. The fee is credited against the build if you continue.

Build

Ship in two-week increments.

6–16 weeks

Working software on a staging environment at the end of every increment, reviewed live with your team. Tests and documentation move with the code, not after it.

What happens

  • Two-week increments with a demo on Friday
  • A staging environment you can reach at any time
  • Automated tests for the rules that cost money
  • Accessibility and performance checks per increment
  • Documentation written alongside the feature

At the end

You get
Working software
Your time
2–3 hours a week
Cadence
Two weeks

No status meeting that could have been a demo. If a date moves, you hear it the week we know, not the week it lands.

Operate

Keep it working, then hand it over.

Ongoing

Monitoring, iteration and a handover pack your next team can use. Most clients keep a light retainer afterwards; some take the keys and run it themselves.

What happens

  • Monitoring, alerts and an on-call rota for launch
  • Monthly iteration against a prioritised list
  • Model and workflow evaluation, where relevant
  • Runbooks for the failures we have already seen
  • A recorded walkthrough and a handover session

At the end

You get
A system you can run
Support
30 days included
Retainer
Optional, monthly

The handover is not an upsell. It is part of the build, priced into the milestone it belongs to.

Working rhythm

What a week looks like.

Four habits that make a build predictable, without a project manager relaying messages.

Friday demo

Working software, not slides. Fifteen minutes, recorded if you cannot attend, with the next increment agreed on the call.

One channel

A shared channel with the people building the work. Questions get answered by the person who knows, not by an account manager.

Written decisions

Anything that changes scope, architecture or a date is written down in the repository, with the reasoning and the date.

Bad news early

Risks are raised when they are suspected, not when they are confirmed. You will hear about a slipping date before it slips.

After launch

The first month decides the review.

Every build includes thirty days of support: fixes at no cost, a monitored production environment, and someone who answers when the pager goes off.

After that, most clients choose between a light monthly retainer for iteration and evaluation, or the handover pack and their own team. Both are normal endings, and we plan for either from the start.

The handover pack

  • Architecture notes, written for the next engineer rather than the client.
  • Runbooks for the failures we have seen, and the ones we expect.
  • A recorded walkthrough of the system, screen by screen.
  • Access, ownership and billing in your name, verified together.
  • A session with the team taking over, questions included.

Next step

Tell us what you’re building.

Send a short brief. You get the questions that matter, a rough shape of the work and a straight answer on fit.

Start a projecthello@intactic.net

No sales sequence