Skip to content
POLARGATE
How we work

How Polargate works: four phases and one loop

Every Polargate engagement runs through four phases: Discover, Build, Grow and Care. Every change inside them runs through the same delivery loop, and it does not stop until two audit passes in a row come back clean.

A man points a pen at a wall screen showing an invoice list and an hours balance, while a woman and a man seated at a wooden table watch in low afternoon sun

Four phases, and why they repeat

Polargate works in four phases. The first time through, they run in order. After that they loop, because a product that stops changing starts to rot.

Discover. Every engagement starts with a paid, fixed-price Discovery Sprint. We read what you already have: the code, the analytics, the spreadsheets your team actually runs the business on. We talk to the people who will live with the result, not only the people who sign. You get back a scope, an architecture, a plan with dates and a fixed price for the build. The document is yours. If you decide to build it with someone else, it still works.

Build. Websites, products, internal portals, mobile apps, AI features and integrations. Senior hands on the keyboard from the first commit. The stack is deliberately conventional where it should be: React and TypeScript in the browser, Postgres and Supabase with row level security behind it, Vercel for hosting, Capacitor when the same codebase has to reach the App Store and Google Play.

Grow. Being found, once there is something worth finding. Classic SEO plus AI-search visibility (appearing in ChatGPT, Perplexity and Google's AI answers is a related but separate discipline), paid media, content, analytics you can act on, and automation that removes repeated manual work.

Care. A monthly retainer with a senior engineer on the other end. Your team opens tickets in our multi-tenant ServiceDesk, sees the hour balance whenever it wants, and gets a written report every month showing what was done. An autonomous fix agent takes the small, well-defined jobs, so human hours go to the ones that need judgement.

The delivery loop

Inside every phase, each change goes through the same five steps.

1. Build. One change, against a stated acceptance criterion. 2. Audit in parallel. Several AI agents review the same diff at once, each with a single brief: correctness, architecture and reuse, interface and interaction detail, accessibility, responsive behaviour, performance, security (tenant isolation, input validation, secrets). 3. Verify adversarially. Every finding goes to a separate agent whose only job is to refute it. Most findings do not survive. On a recent site build, the first round produced 37 findings, of which 4 held up; the second produced 26, of which 3 held up. Acting on all 63 would have been busywork with a price tag. 4. Fix. Confirmed findings only. 5. Re-audit. Back to step two.

The loop stops on two consecutive clean passes, with the production build, the type checker and the automated tests green, and the interface opened by a human on a desktop screen and on a phone. Hard problems take more rounds than anyone would like: an offline-first mobile app for a lodge without reliable connectivity needed eleven, with findings going 42, 28, 9, 15, 11, 4 before it settled.

What you see each week

  • A short written update: what shipped, what is next, what needs a decision from you.
  • A link to the working environment, real and clickable, not screenshots of it.
  • Open questions with our recommendation attached, so deciding takes minutes.
  • The honest state of the plan, including the parts that slipped.

Between updates the client portal stays open: ticket status, hours used and remaining, releases. You should never have to ask where things stand.

Where we stop and ask

Reversible decisions are ours to make, and we make them without calling a meeting. Irreversible ones are yours: production deploys, deleting data, changing authentication or roles, spending money on your behalf. Those stop and wait for you, every time.

We also say no. If a feature does not survive the Discovery Sprint, you hear it before it is built rather than after. And nothing is called done because someone said so: it is done when the checks are green and a person has used it on a phone.

FAQ

Questions, answered

How does Polargate's development process work?
Polargate runs four phases, Discover, Build, Grow and Care, and one delivery loop inside all of them. A change is built, then audited in parallel by several AI agents. Every finding goes to a separate agent that tries to refute it, and only confirmed findings are fixed before the audit runs again. Work stops after two clean passes with build, typecheck and tests green.
Do I have to start with the Discovery Sprint?
Yes, for anything beyond a small fix. The Discovery Sprint is paid and fixed price, and it exists so you commit to a build with a real scope, a real architecture and a real number instead of a guess. It usually pays for itself by killing at least one expensive idea early. The output is yours, even if you build it with someone else.
How do you use AI agents without shipping worse code?
By treating agent output as a claim, not a conclusion. Agents write and review, but every finding is challenged by another agent whose only job is to refute it, and a senior engineer decides. Most findings do not survive: on a recent build, 37 findings became 4 confirmed, and 26 became 3. Nothing merges until build, typecheck and tests pass and a person has used the interface.
What do I actually get every week?
A short written update with what shipped, what is next and what needs a decision from you, plus a link to the working environment you can click through yourself. Open questions arrive with our recommendation attached. Between updates, the client portal shows ticket status, hours used and remaining, and releases, so you never have to ask where things stand.
How long does a project take?
It depends on the scope, and Polargate will not quote a duration before Discovery. That is what the sprint is for: it ends with a plan with dates and a fixed price for the build, based on your codebase and your constraints rather than an average. Phases overlap in practice, so Grow and Care usually start while the last Build items are still moving.
What happens after the site or app goes live?
Care takes over: a monthly retainer with a senior engineer, tickets in our multi-tenant ServiceDesk, a visible hour balance and a written report each month covering what was done. An autonomous fix agent handles small, well-defined jobs so human hours go to work that needs judgement. Care is evolution as well as maintenance, so the product keeps changing after launch.
Who actually does the work?
Polargate is senior led. Pedro Ciordia, founder and CTO, works on the engagement, with a network of specialists brought in when a piece needs one, for example design, media buying or a specific integration. There is no junior layer learning on your budget and no account manager relaying messages. You talk to the person writing the code.
INITIATE

Start the engine

Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price.

Start your project Talk to us