How we work
Diagnose, build, run, scale. Every step priced on its own.
This is the whole engagement, from the first note to a system running in your accounts, in the order you meet it. Nothing is bundled, nothing needs the next step, and most enquiries stop at the first one with a written answer.
- Reply time
- Two business days
- Sales call
- Only if you want one
- First build
- From $1.5K
- Retainer
- None required
to every enquiry, including a no
the first step is written
fixed price, agreed before work starts
cancel anytime where one exists
The four steps
4 steps, each optional, each with what you get and what it costs.
The ladder in full. Every rung is priced on its own and none of them requires the next, which is what makes the first one safe to take.
Step 1: Send the bottleneck
Describe what is being copied, chased, rebuilt, or checked by hand. No call, no form maze.
- A read from the person who would build it
- A one-page first move if it is a fit
- A straight “leave this alone” if it is not
Step 2: Scoping call, only if you want one
Thirty minutes to pressure-test the first move and agree what success is measured on.
- The KPI the work will be judged on
- A fixed price and a delivery window
- What we are deliberately not doing
Step 3: Fixed-price build
The smallest useful system, shipped. Price agreed before work starts and it does not move.
- A working system in your accounts and repository
- Handover documentation
- The measure from step 2, reported against
Step 4: Run it, or take it and go
Where continuity matters, we operate it. Where it does not, you own it outright and we are done.
- Monitoring and an owner for the thing that breaks
- A monthly care plan, only where a running system needs one
- No lock-in: it runs without us either way
The operating model
Diagnose, Build, Run, Scale.
The same four stages, every project. Scale is last on purpose: most projects stop at Build, and a fair number stop at Diagnose, which is a result, not a failure.
Step 1: Diagnose
Diagnose the bottleneck.
Step 2: Build
Build the smallest useful system.
Step 3: Run
Run it where continuity matters.
Step 4: Scale
Scale only after it works.
Inside Diagnose: the same six moves, every time.
When the first step is a discovery engagement rather than a one-page first move, it runs this sequence. The output is something to click, a scope to price, and a plan a team can execute.
Step 1: Identify the problem or opportunity
What is actually costing time or blocking revenue, in the operator's own words.
Step 2: Frame the idea
One sentence on what would exist afterwards, and what it would be judged on.
Step 3: Understand customers and users
Who touches the workflow today, and what they would stop doing.
Step 4: Explore the solution
The two or three shapes the fix could take, including the one that is not software.
Step 5: Define and plan the MVP
The smallest useful system, with what is deliberately out of scope written down.
Step 6: Produce the prototype, MVP scope, and development plan
Something to click, a scope to price, and a plan a team can execute.
The first move
10 free first steps, none of them a call.
Each is a document or a sample with a named input and a named output, written or built by the person who would do the work. Send one input, get something back you can act on or ignore.
Build Map
What to build or replace first, what to leave alone, and in what order.
Automation Map
Every task in a role sorted into three columns: software can do this, a person has to, not worth touching either way.
Data Map
Where the data would come from, how often, what breaks first, and what running it costs a month.
Diagnosis of one broken source
Pick the feed that keeps breaking. We tell you why it breaks and what it would take to stop.
One-week competitor sample
Name three competitors. We collect them for a week and send you what changed.
Thousand-row cleanup sample
Send a thousand rows of the messy file. Get them back deduped, corrected, and filled in.
Pipeline Map
Where demand is leaking, and which leak is worth fixing first.
Bounce read
Send a thirty-day bounce-log export. Get back which of the three causes it is, with the evidence.
Capacity Note
Who would sit in the seat, how the first week runs, and how to end it if the fit is wrong.
A walkthrough of work like yours
Most of the work was delivered under confidentiality. Tell us what you want to see and we show it directly.
The quote
Every quote says all of this.
Hours, tools, and a share of company cost, agreed before work starts. Sometimes the honest answer is that the work is not worth doing, and the quote says so before it prices it.
- The scope, and explicitly what is out of it
- The KPI the work will be judged on
- The number, and the delivery window
- What runs on your accounts versus ours
- What happens if scope changes mid-build
Fixed price
Monthly care plan
Hourly or weekly capacity
Who does the work
The person who scopes it builds it. Where more hands join, they pass the same bar.
Qelv is a US company with a distributed team. We hire from a global pool rather than from one city's salary market, and the engineers on your work are senior: the same people who scoped it. There is no layer of account managers between the person you brief and the person who builds.
Step 1: A live technical task, not a CV screen
Candidates get a real problem from the work, with a deadline and the shortcuts ruled out in writing. What the task is depends on the seat: a reverse-engineering problem for a data placement, a schema and a broken migration for a backend one.
Step 2: A phased trial, the second phase paid, under NDA
The first phase screens. The second is paid and runs on the client's actual work, so the decision is made on delivery rather than on interviews.
Step 3: Placement on the client's terms
Biweekly billing or a monthly block, in the client's repository under the client's standards, with the founder still accountable for the work.
Step 4: The bar stays written down
The screening task, the trial phases, and the hand-off are documented per placement, which is what makes the next one repeatable.
We do not discount by cutting review or testing
The cheapest way to lower a quote is to skip the work that catches problems later. We price that work in and say so.
We do not staff junior and bill senior
You are told who is doing the work. Where a task genuinely suits a less senior engineer, it is priced that way.
We do not quote low and change-order up
A fixed price is agreed before work starts and does not move. If scope changes, that is a new conversation with its own number, not a surprise on an invoice.
What you own
You own everything.
Code lands in your repository, systems run in your accounts, documentation comes with the handoff. If we stop working together, it all keeps running.
After the build
Run it, or take it and go.
Where continuity matters, we operate it. Where it does not, you own it outright and we are done.
- Monitoring and an owner for the thing that breaks
- A monthly care plan, only where a running system needs one
- No lock-in: it runs without us either way
Elsewhere on the site
Related
- How it runsHow a price is builtHours, tools and a share of company cost, agreed before work starts. The arithmetic is public.
- How it runsAbout QelvWho does the work, the two owned ventures, and the company behind them.
- ReferenceQuestions and answersEverything asked often enough to be written down, grouped.
Where to next
That is the whole model. The first step is the free one.
Send a few sentences on what is still being done by hand. The reply says which of the first steps fits, or that the fix is not software.