Skip to content
ComputingAmerica

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

    One conversation to work out whether this is a problem we should be working on together.

    We ask what the process looks like today, what breaks, what you’ve already tried, and what the cost of the status quo actually is. If the answer is that you should buy something off the shelf, keep the spreadsheet for another year, or hire rather than contract, we’ll say so on this call. That happens often enough that we consider it part of the job.

    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, including “don’t build this”
    • 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

    2–4 weeks · 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 software estimates 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. A discovery that ends in a recommendation not to proceed has done its job and is priced accordingly.

    What happens

    • Process observation with the people doing the work
    • Domain and data modeling
    • Integration and constraint mapping across the existing estate
    • Survey of the commercial products that already cover part of the scope
    • 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
    • A build, buy or extend recommendation, with the products we considered named — including the platform tier and what it would cover on its own
    • 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

    ExitEverything produced is yours whether or not you continue with us.

  3. Phase 3

    First release

    8–16 weeks

    A small senior team ships something genuinely useful into production. Real users, real data, real load.

    We do not run a six-month build behind a curtain. The first slice goes to a real environment inside the first three weeks, 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, at any point, 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 prioritise 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

    Hand-off

    2–6 weeks

    Planned from the first week, so that leaving is a scheduled event rather than a negotiation.

    Our commercial interest and your interest diverge exactly here, so we make the answer structural: your engineers are in the codebase from day one, documentation is written as the work happens, and every engagement has an explicit hand-off phase. Some clients keep us on retainer afterward. Plenty don’t, and that’s a successful outcome too.

    What happens

    • Paired work with your team on live changes
    • Runbook and architecture walkthroughs
    • Transfer of every credential, account and domain
    • Agreed support window at a reduced rate

    What you get

    • Complete documentation and runbooks
    • All accounts and access in your control
    • A named support contact for the agreed window

    ExitYou own everything. There is nothing left to transfer.

Operating principles

Six 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.

  • We’ll tell you not to build it

    Roughly one in five inquiries ends with us recommending an off-the-shelf product, an internal hire, or doing nothing for another year. Being wrong about this once costs us a project. Being wrong about it consistently costs us the business.

  • You own everything

    Code, infrastructure, accounts and documentation, in your name from the first commit. No escrow, no runtime licence, no clause that makes leaving expensive.

  • Senior people, small teams

    Four experienced engineers beat twelve inexperienced ones on work like this, and cost less. 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.

  • 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.

    • 2–4 weeks
    • Fixed price agreed in advance
    • All artifacts yours regardless of what follows
    • No obligation to continue
  • Sustained product development

    Dedicated team

    A cross-functional team (engineering, design and product) working on a monthly cadence with a roadmap you control and can change at any sprint boundary.

    • 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 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
    • Access to our full bench for review
    • 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 actually 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 could each ship to production on their own, 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

    “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.

    • Present assignment of all intellectual property rights created for you, not copyright alone
    • Every engineer and subcontractor under written assignment before they touch the codebase
    • Any third-party or open-source component identified, with its licence and any fee attached
    • Repositories, cloud accounts and domains in your name from the first commit, so there is nothing to transfer later
    • 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 afterwards
    • 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 defence 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
    • No source code escrow, because escrow is what you need when the vendor keeps the source

We work under client paper regularly and will redline yours rather than insist on ours. 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.

  • We would rather give you a number here than make you book a call for one. Discovery is a fixed fee, generally $25,000–$60,000 depending on the size of the estate and how many systems we need to map. A first production release with a small team is usually a $180,000–$450,000 range of work. Those are what engagements of this shape cost and what we would expect to quote — not an average of ours, because we are new enough that an average would be three numbers in a trench coat, and you should discount any firm that pretends otherwise. Yours is quoted against a written scope, in phases, with each phase’s cost and exit criteria fixed before it starts, so the decision to continue is yours at every boundary. If your budget is smaller than that, say so on the call: we will tell you whether the problem is buildable for it, including when the answer is no.

  • Honestly? On résumé, badly, 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, named clients in your industry and reference calls we cannot match yet. If your decision rests on track record alone, hire one of them; several are genuinely excellent and we will name them on the call. The difference we would ask you to weigh is commercial rather than technical. We publish what work costs, the method by which we produce an estimate and who pays when it is wrong, and the terms on which you leave — before you talk to us, not in a negotiation. Very few firms in this tier publish the last two, and the reason is that they are commitments rather than claims: they constrain us, they are checkable against what we actually do, and copying them costs something. That is the trade on offer. Longer history and more logos on one side; published commitments and a smaller senior team that will tell you when not to build, on the other.

  • 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. If your integrator can do it inside their platform and that is genuinely the right answer, we will tell you so and there is no engagement here. And 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.

  • Often, yes — several of our engagements began as someone else’s half-finished build. We start with a paid assessment of what exists: what the code and data are worth keeping, what the remaining work actually is, and what it would cost to finish versus to replace. Sometimes the honest answer is that the foundation is sound and the project just lost its owner. Sometimes it is that you should throw it away, and we will tell you that too, in writing, before you commit to a build.

  • Thirty days' notice after the first release, for any reason, with no termination fee. Everything built to that point is yours and deployed in your accounts. We’d rather you were able to leave easily and chose not to.

  • Yes. We work under client paper regularly and carry professional and cyber liability coverage. Security is handled through an exhibit written for your data rather than a pointer to our own policy: we notify you of any actual or suspected incident within 24 hours, leave the content and timing of any notification to your customers or regulators entirely in your control, sign BAAs where PHI is involved, and support joint security testing. Questionnaires are part of onboarding rather than an afterthought. Send the requirements early and we’ll flag anything we can’t meet.

  • Usually one of three ways, and we will tell you which is fastest for your institution rather than the one that suits us. First, subcontracting: we work under a prime who already holds the vehicle, which is the most common route for a firm at our stage and needs nothing new from your procurement office. Second, your own delegated authority: many institutions can issue a purchase order directly for services under their own limit, and those limits are set locally rather than centrally, so the number is yours to confirm. Third, a cooperative or state vehicle you already use. Being plain about that third one: we hold no cooperative or state contract awards today. Awards on those come through competitive solicitation cycles rather than on request, they are published, and any vendor implying otherwise is worth checking. If a vehicle is the only viable path for you, the honest answer is that we are the wrong firm this fiscal year, and we will say so on the first call rather than in month two.

  • All in the United States, across several time zones. We don’t subcontract delivery offshore. If a role requires clearance, citizenship or on-site presence, tell us early and we’ll be direct about whether we can staff it.

  • By present assignment of all intellectual property rights, not by calling it work made for hire. Work for hire is a copyright doctrine: it doesn’t reach patents or trade secrets, and it doesn’t apply to a contractor’s work at all. Every person who touches your codebase, employee or subcontractor, is under written assignment before they start, and any third-party or open-source component we use is listed with its licence.

  • Acceptance criteria go in the statement of work, in objective terms, before the work starts. If something doesn’t meet them we fix it at our cost inside a defined window. Nothing is ever deemed accepted because time passed, and a holdback on each phase is released only on acceptance of that phase. If we can’t get it right, you stop paying for it.

  • Every change is priced and signed before work on it starts. We also rewrite our own assumptions as your obligations with dates attached, because an unstated assumption is how a contractor creates an exit and a change-order revenue stream at the same time. On estimated work we agree an overrun mechanism up front: modest variance is ours to absorb as the normal play in an estimate, and a large miss means the estimate was a guess, which is our problem rather than yours.

  • Mutual, with the usual carve-outs: breach of confidentiality, IP infringement indemnity, gross negligence and willful misconduct sit outside the cap rather than inside it. A cap that swallows the indemnity makes the indemnity decorative. We’ll negotiate the number against the size and criticality of the engagement, and we’d rather have that conversation on the first call than in week six.

  • Everything, because it was never anywhere else. Code, infrastructure and accounts are in your name from the first commit. Data is exported in a platform-neutral format as well as ours and then certified destroyed to NIST SP 800-88. Documentation and runbooks are written as the work happens, not assembled during a hand-off. There is no escrow arrangement because there’s nothing we hold that you don’t.

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 you should be building this at all.