How we work.

How an engagement starts

There is a store. Four engagements are published with their prices, and you can buy one without speaking to a human first.

• Product Feasibility — Market to Motion, from $3,500. A fixed-scope investigation that tests one product idea before anyone commits an engineering budget: market reality, technical risk priced by a working spike, a three-band cost envelope, and a build or do-not-build recommendation with the reasoning shown.
• Service Configurator, $9,650 core build, up to $27,650 fully loaded. A company storefront you configure in the browser and buy at checkout. Self-checkout, no meeting required.
• Product Development — Enterprise Build, from $25,000. Architecture, engineering and delivery of software carrying real users, real money and real data.
• GTM — Growth Loop Program, $5,000 per month, flat and recurring. Positioning, messaging, launches, distribution, events, partnerships, AI answer-engine discoverability, and a written report each month.

"From" means a floor, not a teaser. A price that starts with "from" is the least that engagement costs, not a sample of what it might cost. And the configurator is a real checkout, not a quote request: you pick the add-ons, the price updates as you go, and you pay in the browser.

If you would rather talk first, book a call or use the contact form. A call is a convenience, not a gate. There is no rate card, no billable hours and no proposal cycle to get through first.

How scope is fixed

Every engagement is fixed-scope and publicly priced. That constrains us first: we cannot recover a bad estimate by billing more hours, so scope has to be written precisely enough that both sides can tell whether it was delivered.

Fixed scope only means anything if it is written down: what will exist when the engagement is finished, what is excluded, and in what order. That is the standard the price is set against. For the Configurator, much of it is decided by what you select at checkout — the add-ons are the scope. For an Enterprise Build, architecture is settled before feature code, so the shape of the thing is agreed before the expensive part starts. For Feasibility, the scope is the question being answered, plus the working spike that prices the technical risk.

When scope changes mid-engagement

Assume it will. A fixed scope is not a claim that nothing new will be learned once work is underway. So changes get written down and priced rather than absorbed quietly.

• Swaps are handled as swaps. A change that is equivalent in effort and replaces something already in scope is written into the scope in place of what it replaces, and the swap is recorded rather than agreed verbally.
• Additions are priced as their own fixed-scope item. There is no hourly rate for an addition to disappear into, so it gets a number and a delivery effect before anything is built. Approve it, defer it, or drop it.
• Nothing enters the build unapproved. An unfunded change does not silently displace funded work and quietly move the date.

Standard Configurator delivery is 6 to 8 weeks and is included in the price. Priority delivery of 3 to 4 weeks is a paid add-on at $1,800, because compressing a schedule costs real capacity, and pricing that at zero is how dates slip.

Your cloud, your repositories

An Enterprise Build lives in your cloud accounts and your repositories from the first commit. Not at the end, not at handover, not after a migration project. The first commit lands in a repository you own, in an organization you control, against infrastructure billed to you.

This is deliberate and it costs us leverage. You can revoke our access on any day of the engagement and keep everything built so far. There is no hosting arrangement you must keep paying for in order to keep your own software running. The commit history, the infrastructure definitions and the deployment path are yours to inspect while the work is happening, not after.

The same instinct runs through what we build for ourselves: EVERJUST.APP is a business operating system that runs on the customer's own database, not on a shared tenant.

And the same principle applies down the range: a Feasibility engagement ends in a written recommendation with the reasoning shown, including the parts that argue against building. You are buying an answer you can act on, not a document that only points one way.

What you are responsible for

Fixed scope only works if the inputs arrive. Your side:

• One decision-maker. Someone empowered to approve scope changes and settle internal disagreements. A scope question routed through a committee does not get answered, it gets deferred — and a deferred decision is a date moving.
• Access, early. Cloud accounts, repositories, domain and DNS, and any third-party system the build has to talk to. Access is the one input we cannot supply for ourselves. Work that depends on a system we cannot reach does not start.
• Answers while the work is waiting. Blocking questions are raised in writing rather than saved for a call. A workstream waiting on an answer cannot move, and that delay lands on the schedule rather than disappearing into it.
• Content and assets you own. Copy, logos, product information, legal text. We will write around gaps; we will not invent facts about your business to fill a page.
• Permission to publish. On GTM especially. A growth program that cannot publish without clearing a long approval chain will not compound, because a loop only compounds if it keeps closing.

The rhythm of an engagement

The cycle is written, not verbal. You get a written update covering what shipped, what is next, what changed, and what is blocked and on whom — so the state of the engagement lives in a record rather than in someone's memory of a call. On a build, the work is visible in your own repository as it happens, so the update summarizes something you could have watched yourself.

Calls are available and you can book one at any point in an engagement. The design intent is that you should not need to. If the only way to find out where the work stands is to get someone on the phone, the written record is not doing its job.

The GTM track adds a written report each month: what was launched, what was distributed, what moved and what did not, and what the next month does about it. That monthly report is part of the program, not an upsell.

Handover, and what you own at the end

Because the work was in your accounts throughout, handover is a closing procedure rather than a migration. At the end of a build you have the running software, the repositories and their history, the infrastructure definitions and the deployment path — accumulated in your accounts while the work happened, not assembled for a handover meeting. Our access is removed when you say so.

The standard we hold the work to is simple: another engineer, reading only what is already in your accounts, can pick the system up. After launch the Configurator gives you a choice rather than an obligation — handover is included, or you can take 30-day hypercare at $1,500, or a 3-month care plan at $6,000. One of them, or none. Not one of them is a condition of receiving your own code.

When you buy both tracks

BUILD and GTM are separate purchases with different shapes. A build is a one-time fixed price. GTM is $5,000 per month, recurring, for as long as you want it running. Neither requires the other.

When you buy both, they interlock. Positioning feeds the build: what you are claiming determines what has to be true in the product, and that conversation is cheaper before the feature code exists. The build feeds distribution: launches, discoverability and partnerships need something real to point at, and a growth loop attached to a product that does not exist is a content program in disguise.

The two tracks are reported together, so you are not reading two accounts of the same period. Scope changes are still handled per track, because the money is structured per track.

When we are the wrong choice

We would rather lose the engagement than take one that will not work. Do not hire us if:

• You want hours, not outcomes. There is no rate card and no timesheet. If procurement needs a blended hourly rate and a headcount ramp, we do not fit it.
• You want the scope open. If the requirement is genuinely unknowable and you want to discover it by building for six months, buy Feasibility first, or hire staff.
• You want a proposal cycle. The prices are published. We do not produce speculative decks to compete against numbers that were invented for the occasion.
• You want to be told the idea is good. Feasibility can return do-not-build. If a negative answer would be unwelcome, you are buying the wrong product.
• You want us inside your daily standup. We work in your systems, not inside your management structure.
• You want marketing detached from a product. The Growth Loop is designed to compound over months. It is not an emergency service for a launch that is already on the calendar.
• You need the cheapest option. Fixed scope prices the risk we absorb. Someone will always be cheaper by leaving that risk with you.

What we build for ourselves is on the portfolio page: EVERJUST.APP, CustomAgents, Custom Domain and FaceSmash — four products we built and run. That is the evidence we would rather be judged on, and there is more on about. We hire the same way we sell: apply, a conversation, a paid real problem, a decision — no whiteboard theatre, and the open roles are listed. If you want to start, the store is open.