Skip to content
Talk to an engineer

How we work

Fixed-scope discovery, then continuous delivery.

Five phases, each with a defined exit that’s yours to take. We designed it this way because the alternative (asking clients to commit before anyone knows what they’re committing to) produces the projects everyone regrets.

  1. Phase 1

    First call

    45 minutes · no charge

    What breaks today, what the status quo is costing, and which division would own the fix.

    We ask what the process looks like today, what breaks, what you’ve already tried, and what the status quo is costing you. By the end of the call both sides know whether this is a problem worth working on together, which division would own it, and what the next step costs.

    What happens

    • Walk through the current process and where it fails
    • Establish what a good outcome would be worth
    • Identify hard constraints: compliance, deadlines, existing vendors
    • Agree whether discovery is justified

    What you get

    • A direct recommendation on the next step
    • A discovery proposal with a fixed fee, if it’s warranted

    ExitYou leave with a recommendation. There is nothing to cancel.

  2. Phase 2

    Discovery

    1–4 weeks typical · fixed fee

    Paid, fixed-scope, and it ends in a plan you could hand to another firm, plus working code proving the riskiest assumption.

    Discovery exists to remove the uncertainty that makes an estimate worthless. We spend time where the work happens, model the domain, map the systems we’ll have to integrate with, and build a technical spike against the single riskiest assumption in the project. One week is the shape for a single system. Where there is more estate to map the entry engagement is longer and is sold as its own thing (a modernization assessment or an OT discovery runs several weeks), and the service page for the work you are buying states its own duration. All of them are quoted against your estate and your budget rather than published as a range, because the thing that moves the number is how much of it there is; ask on the first call and you will get a figure before you commit to anything.

    What happens

    • Process observation with the people doing the work
    • Domain and data modeling
    • Integration and constraint mapping across the existing estate
    • Technical spike on the highest-risk assumption
    • Interface prototypes tested with real users
    • Sequencing into independently valuable releases

    What you get

    • Solution architecture and domain model
    • Release plan with independently shippable slices
    • Estimate range with the assumptions behind it stated
    • Working spike code and a clickable prototype
    • Risk register with mitigations

    ExitA fixed-fee engagement with a defined end. Continuing is a separate decision.

  3. Phase 3

    First release

    1–8 weeks typical

    A small senior team puts something real into use: a production system, a pilot running on the floor, or a finding you can reproduce.

    We do not run a six-month build behind a curtain. The first slice goes to a real environment in the first week, and to real users as early as the work allows. Weekly demos are of running software, not status. If priorities change, and they do, the plan changes at the next sprint boundary rather than at the next contract negotiation.

    What happens

    • Weekly demos of working software, not slides
    • Continuous deployment to a real environment from week one
    • Automated tests written alongside features, not after
    • Your engineers in the codebase and in code review from the start
    • Architecture decisions recorded as they’re made

    What you get

    • Production system carrying real work
    • Infrastructure as code and reproducible environments
    • Test suite covering the critical paths
    • Architecture decision records

    ExitThirty days’ notice from the end of this phase, for any reason.

  4. Phase 4

    Iterate & scale

    Ongoing, by agreement

    The system grows against evidence from production rather than against a plan written before anyone used it.

    Once real usage exists, it should drive the roadmap. We instrument the flows that matter, watch where people struggle, and prioritize against that. This is also where the unglamorous durability work happens: performance under real load, cost per transaction, on-call ergonomics, and the operational documentation your team will depend on later.

    What happens

    • Usage instrumentation on the flows that matter
    • Performance and cost tuning against real traffic
    • SLOs, alerting and on-call runbooks
    • Roadmap review every month, changeable every sprint
    • Security review and dependency hygiene on a schedule

    What you get

    • Monthly delivery and reliability reporting
    • SLOs with dashboards and an alert policy
    • A roadmap you set and can change

    ExitMonth to month. No minimum term after the first release.

  5. Phase 5

    Maintenance & support

    Ongoing, for as long as you want it

    We keep the system healthy after launch, and your team can take it over whenever you’d rather run it yourselves.

    Most systems need someone watching them after the first release: dependencies age, traffic patterns change, and the operating system underneath moves whether or not the software does. We stay on to do that work: patching, upgrades, monitoring, and the small changes that keep a system fitting the business. None of it is a lock-in. Your engineers are in the codebase from day one and documentation is written as the work happens, so when you want to run it in-house we hand over rather than negotiate.

    What happens

    • Dependency, platform and security patching on a schedule
    • Monitoring, alerting and incident response within an agreed window
    • Small changes and enhancements as the business shifts
    • Runbook and architecture walkthroughs, and paired work with your team
    • Transfer of every credential, account and domain whenever you ask

    What you get

    • A named support contact and an agreed response window
    • Complete documentation and runbooks, kept current
    • All accounts and access in your control

    ExitNo minimum term. Stop whenever you like; nothing has to be transferred back.

Operating principles

Four commitments, and what each one costs us.

Every one of these has cost us work. That’s roughly how you can tell they’re real.

  • Senior people, small teams

    The people who sell the engagement are the people who deliver it. There is no bait-and-switch to a junior bench, because we don’t have one, and no account manager sitting between you and whoever is writing the code.

  • Onshore, one time zone

    Every engineer is US-based. No overnight hand-off, no requirement that ambiguity be resolved in writing before anyone can start, no eleven-hour round trip on a question that takes ninety seconds to answer.

  • Ship weekly, from week one

    Working software in a real environment every week is the only honest status report. Anything else measures activity rather than progress.

  • Boring technology, deliberately

    We choose well-understood tools with long support horizons and large hiring pools, and reserve novelty for the places it earns its risk. Your system has to be maintainable by people we haven’t met.

Commercials

Four structures, chosen by how much is still unknown.

We’ll recommend one on the first call. It’s usually the smallest one that fits, because the point of discovery is to earn the right to a bigger commitment.

  • Starting anything meaningful

    Fixed-fee discovery

    A defined price for a defined deliverable: architecture, plan, estimate range, prototype and spike code. It is the only responsible way to price work that hasn’t been specified yet.

    • 1–4 weeks, depending on how much estate there is to map
    • Fixed and agreed in advance, against your budget and requirements
    • Deliverables defined in the engagement agreement
    • No obligation to continue
  • Sustained delivery against a roadmap

    Dedicated team

    A cross-functional team working on a monthly cadence with a roadmap you control and can change at any month boundary, engineering, design and product on a build; the equivalent specialists where the program is instrumentation or security.

    • Monthly, after the first release
    • Named individuals, not a resource pool
    • Thirty days’ notice, any reason
    • Scale up or down at month boundaries
  • Well-specified scope with a hard date

    Outcome-based project

    When discovery has removed enough uncertainty, we’ll price a defined outcome and carry the delivery risk. We only offer this when we genuinely can, which usually means after discovery.

    • Fixed price against a defined scope
    • Milestone-based payment
    • Change control by written agreement
    • Only offered post-discovery
  • Reinforcing a capable in-house team

    Embedded engineers

    Senior engineers (software, firmware or security, depending on what you are short of) inside your team, in your process, under your technical leadership, with our review, standards and support behind them.

    • Monthly per engineer
    • Your backlog, your ceremonies
    • Our review and standards behind them
    • Thirty days’ notice

We don’t bill by the hour

Not on principle, on arithmetic. Tooling has made the implementation half of this work materially faster, and an hourly rate means every improvement we make to how we work arrives as a smaller invoice; we would be paying ourselves to be slower. So discovery is a fixed fee, delivery is a monthly team or a priced outcome, and the incentive points the same way yours does: at the thing working, not at the hours it took.

After launch, on purpose

Most of a system’s life happens after the first release, and it is where firms quietly stop being accountable. You can keep a reduced standing team, buy a defined support window at a lower rate, or take the whole thing in-house with our hand-off phase and be done with us, and we will tell you which of the three we think fits. Reliability targets are set per system against what it does, not sold as a support tier, and whichever you choose it is month to month.

Estimates

How the number is produced, and who pays when it’s wrong.

Every firm will tell you their estimates are honest. That is not checkable, so here is the method instead. It is the same method whether you are a prospect or three phases in, and the parts of it that constrain us are the point.

  1. Estimate slices, not features

    A feature list contains no delivery risk, so estimating one produces a number that cannot be wrong until it is very wrong. We break the work into slices that are each independently deliverable, and estimate those. It is slower, and it is the reason a range narrows as the project proceeds instead of quietly widening.

  2. Give a range, and say what sits at each end

    You get a low and a high, plus the specific conditions that put the work at either end, not a single number with a padding factor buried in it. If we cannot describe what would have to be true for the top of the range, we do not understand the work well enough to have estimated it.

  3. Write our assumptions as your obligations, with dates

    Every estimate rests on things we assume about your side: an environment exists, someone can approve, a system has a test instance, a vendor answers. Those are listed as dated obligations in the statement of work rather than left implicit, because an unstated assumption is how a contractor manufactures a change order and calls it your fault.

  4. Attach a confidence, and say what would raise it

    Ranges carry a confidence level and the reason it is not higher. Usually the answer is one unknown that can be resolved by building something small, which is why discovery includes a spike against the single riskiest assumption rather than a longer document.

  5. Agree who pays for a miss before the work starts

    Modest variance is ours to absorb; that is the normal play in any estimate. A large miss means the estimate was a guess dressed as an estimate, which is our failure and not a change in your scope. The threshold between those two is a number in the statement of work, agreed before anyone starts, not a conversation in week nine.

  6. Show the last estimate against what it actually cost

    At every phase boundary you get the previous estimate next to the actual, and an explanation of any gap. This is the part firms leave out, and it is the only one that makes the rest verifiable: a method you cannot audit is a claim about our character, and you have no reason to take our word for that yet.

What the estimate contains

  • A low and a high figure, with the conditions that produce each
  • The slices behind them, priced individually
  • Our assumptions restated as dated obligations on your side
  • A confidence level, and the one unknown that would most improve it
  • The overrun threshold and who carries each side of it
  • Enough detail that another firm could price the same scope from it

Terms

What we’ll sign, before anyone sends paper.

Buyers with experienced counsel arrive asking for a specific list of protections, and are usually refused most of them. Here is our answer to that list, in advance. None of it is unusual for us; all of it is unusual to see written down.

  • Ownership and licensing

    “Work made for hire” is a copyright concept. It says nothing about patents or trade secrets, and it does not reach work done by a contractor, which is why the mechanism matters more than the label.

    • Ownership and licensing settled in writing in the engagement agreement, before any work starts
    • Whatever is agreed is agreed by express assignment rather than by relying on work-made-for-hire language
    • Every engineer and subcontractor under written assignment before they touch the codebase, so there is a clean chain of title to assign
    • Any third-party or open-source component identified, with its license and any fee attached
    • No feedback clause. What you tell us about your business stays yours
  • Acceptance and payment

    Acceptance testing is the protection most services contracts leave out, and the one that decides what happens when a deliverable is not what you asked for.

    • Objective acceptance criteria written into the statement of work, not decided afterward
    • Nothing is “deemed accepted” because time passed
    • Rework to meet the agreed criteria is at our cost, inside a defined window
    • Payment tied to milestones and acceptance rather than to the calendar
    • A holdback on each phase: a share of the fee we don’t invoice until you accept that phase
  • Scope and change

    Underbidding a project and recovering the difference through change orders is a known pattern. The defense is a specific scope and a change process you control.

    • A statement of work in active voice, naming who does what and by when
    • Our assumptions rewritten as your obligations, with dates, so neither side discovers them late
    • Every change priced and signed before the work starts
    • Estimates given as a range with the assumptions stated, and a shared overrun mechanism agreed in advance
    • No legal terms buried in a statement of work
  • People

    The named team on the proposal and the team that arrives are frequently different. Staff turnover is the most reliable predictor of cost and delay on a long engagement.

    • Key personnel named in the statement of work and not substituted without your consent
    • Interview anyone you want to before they start
    • You can require removal of anyone, for any lawful reason
    • No charge for the ramp-up time of a replacement we initiated
    • All delivery performed in the United States. Nothing subcontracted offshore
  • Data and security

    Most privacy law holds you responsible for a breach whether it was your fault or your vendor’s. The contract is where that gets allocated.

    • A security requirements exhibit specific to your data, not a pointer to our then-current policy
    • Written notice of any actual or suspected incident within 24 hours
    • You control the content, timing and method of any notification to your customers or regulators
    • Log files and forensic cooperation preserved and provided
    • A signed BAA where PHI is involved, and joint security testing where you want it
  • Leaving

    The cost of leaving is set on the day you sign, not on the day you go.

    • Termination for convenience on thirty days’ notice after the first release, no fee
    • A hand-off phase in the plan from the start, not negotiated under pressure at the end
    • Your data returned in a platform-neutral format as well as ours, then certified destroyed to NIST SP 800-88
    • Documentation, runbooks and architecture decision records written as the work happens
    • A named handover contact for a defined window after the last day, so the last question does not go unanswered

We work under client paper rather than asking you to work under ours, and we redline rather than refuse. Send your master agreement and security requirements with the first brief and we’ll flag anything we can’t meet before you spend money on us.

Questions

Money, timing, paperwork, and what happens if it goes wrong.

  • Yes, and it is usually the fastest way to get a useful answer: several of the pieces we publish end by asking for exactly that. Two things worth knowing first. This is an ordinary web form: it is encrypted in transit and the message lands in our mailbox and our own console, but it is not a secure document channel, so redact freely. A workbook with the numbers changed, a clause with the parties removed, a day of messages with the identifiers swapped: each of those answers the question as well as the original does, and we would rather read a redacted one. And if you would rather have an agreement in place before you send anything, say so in a line: we work under your paper rather than asking you to work under ours, and we redline rather than refuse.

  • Custom builds start around $40,000–$60,000; below that an off-the-shelf tool is usually the honest answer and we will say so. Past the floor it is quoted against your budget and what you actually need, rather than printed as a range that would be wrong for most of the people reading it. Two lines do carry a published price, the website build and its care plan, and they are on the services page. Discovery is a fixed fee, agreed in advance. Delivery is quoted against a written scope, in phases, with each phase’s cost and exit criteria fixed before that phase starts, so the decision to continue is yours at every boundary and there is no open meter. There is no minimum engagement: the shortest piece of work on this site took an hour, and the one beside it took four weeks. Tell us the budget you have on the first call and we will tell you what is achievable inside it, including when the honest answer is that it is not. If you would rather know before you spend a call, put the budget you have in your first message and we will answer that question in the reply.

  • On résumé, they are ahead, and you should discount anyone who tells you otherwise. There are onshore firms in this space that have been doing it for eighteen, thirty, even fifty years, with senior engineers and named clients in your industry. The difference we would ask you to weigh is structural rather than technical. Most firms our competitors’ size specialize in one layer and subcontract or decline the rest, so the seams between the control network, the application, the estate and the security review end up owned by whoever is left in the room. We run those as four divisions inside one company, staffed separately and briefed together, which is why the escalation path ends somewhere useful instead of at a vendor boundary. That is the trade on offer: longer history and more logos on one side, and on the other a smaller senior team that can follow the problem across every layer it touches.

  • Discovery usually starts within two to three weeks. A full delivery team typically needs four to six weeks of notice, though we occasionally have earlier availability; it’s worth asking.

  • Usually between them, and the honest answer is that we want both of them to stay. Your integrator should keep the control layer, the PLCs and everything at or below the line where a mistake stops production; they hold vendor certifications and site knowledge we are not going to duplicate. Your ERP partner should keep everything inside the ERP, where they know the data model and the upgrade path far better than we will. What often has no owner is the layer in between: the browser-facing application your operators actually use, the queue and the retry between the two systems, the identity and audit trail that lets you answer a question about one record on one day. Neither of those firms is structurally set up to own that, and both need it to exist. That layer is what we are for, and we would rather scope it beside your existing vendors than ask you to replace them. If the cleanest route is for us to sit under your existing vendor’s contract rather than beside it, we will work that way; say so early, because it changes the paperwork rather than the plan.

  • Preferably. Most of our best outcomes are blended teams. Your engineers know the business; ours bring practices and capacity. It also makes the eventual hand-off almost free.

Next step

Tell us what’s breaking.

Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.

Reply
A person replies, not a sequence: within one business day, from someone who would be on the engagement.