approach

How a project runs

The same five stages, in the same order, on every project. Each stage ends with something concrete you can see, click, or keep — so you always know exactly where things stand.

Discover

We start with conversations, not contracts. What problem is this product solving, for whom, and how will you know it worked? We review anything that already exists — code, designs, spreadsheets, the workaround your team invented — and identify the smallest version worth building first.

Then we put the scope in writing: what's in, what's explicitly out, what it costs, and how long it takes. No project starts before both sides have agreed that document.

you get → a written scope, plan & fixed price

Design

Before code, screens. We map the user flows — including error states, empty states, and the unhappy paths most designs skip — then turn them into clickable Figma prototypes. You, and ideally a few of your users, click through them and tell us where they break.

Changing a prototype costs minutes. Changing built software costs weeks. This stage exists to spend the minutes instead of the weeks.

you get → clickable prototypes & a design system

Build

We work in short cycles with a working version you can open in your browser (or on your phone) from the first weeks — not a big reveal at the end. Every week you see progress, try it, and steer.

When we hit a trade-off — speed versus polish, this feature versus that one — we bring it to you with a recommendation and the reasoning, in plain language. You decide; we implement.

you get → a usable build, updated weekly

Launch

Launch is engineered, not celebrated into existence. Production environment, monitoring and alerts, error tracking, backups, and a rollback plan — all in place before real users arrive. If it's a mobile app, we take it through store review and staged rollout.

You also get a proper handover: the source code in your accounts, credentials in your hands, and documentation written for whoever maintains this after us — even if that's still us.

you get → a live product, in your name, documented

Iterate

The first release is the beginning of the useful part. Real usage tells us which assumptions were wrong — so we watch how the product is actually used, fix what friction appears, and ship improvements in small, safe releases.

Some clients keep us on an ongoing cadence; others come back per milestone. Both work. What we won't do is disappear after launch.

you get → measured improvements, release by release

principles

How we work, whatever the project

Scope in writing

Every engagement starts with a written scope and price agreed by both sides. Changes are welcome — they're discussed and written down too, before they're built.

One team, end to end

The people who design your product are the people who build it. Nothing is thrown over a wall, and no decision gets lost in a handoff.

Plain language

We translate technical trade-offs into consequences you can weigh: what it costs, what it risks, what it makes possible. Jargon is a smell, not a service.

You own everything

Code in your repositories, infrastructure in your accounts, credentials in your password manager. If we vanished tomorrow, your product wouldn't.

Working software over decks

Progress is something you can click, not a slide about something you'll click later. Demos are weekly and unrehearsed.

Built to maintain

We choose proven tools over fashionable ones and write code for the developer who inherits it. The cheapest feature is the one that never breaks.

Sound like a fit?

Tell us about your project and we'll come back with an honest read on scope and the smallest sensible first step.

Start a project

hello@progarma.com