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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yes, and the first thing we hand back is an assessment rather than code. It is a paid piece of work: what the code and the data are worth keeping, what the remaining work actually is, and what finishing would cost against what replacing would cost, with the reasoning written down so you can take it to somebody else. 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. What we will not do is quote a finish price off a demo and a repository we have not read.
Thirty days’ notice after the first release, for any reason, with no termination fee. What you take with you when you go is settled in the engagement agreement before any work starts, and the hand-off phase is in the plan from the beginning rather than negotiated on the way out. We’d rather you were able to leave easily and chose not to.
Yes. We work under client paper rather than asking you to work under ours, and we redline rather than refuse. Security is handled through an exhibit written for your data rather than a pointer to our own policy, and the terms we will agree to there include notification of any actual or suspected incident within 24 hours, the content and timing of any notification to your customers or regulators left entirely in your control, a BAA where PHI is involved, and support for joint security testing. Questionnaires are part of onboarding rather than an afterthought. Send the requirements early, including whatever insurance you require us to carry, 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, all in Central time. 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.
In the engagement agreement, in writing, before any work starts. Ownership and licensing are commercial terms rather than something we publish a standard answer to here, and they are settled with you during scoping. What we will say in general is that we do not rely on “work made for hire” language to do it: work for hire is a copyright doctrine that does not reach patents or trade secrets, and it reaches commissioned work only in nine narrow statutory categories that software is not one of, so whatever is agreed is agreed by express assignment. Any third-party or open-source component we use is listed with its license.
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 carve-outs that sit outside the cap: IP infringement indemnity, gross negligence, willful misconduct, and deliberate misuse of your confidential information. A cap that swallows the indemnity makes the indemnity decorative. We draw one line deliberately: a confidentiality breach we caused on purpose is uncapped, and one caused by a mistake sits under the cap or under a higher security-specific cap we will agree. We would rather tell you where our insurance actually reaches than promise an unlimited number that nothing funds. We’ll negotiate it against the size and criticality of the engagement, and we’d rather have that conversation on the first call than in week six.
Whatever the engagement agreement says, and it says it before any work starts rather than at the end. Ownership, licensing and where the code and infrastructure are held are settled in writing during scoping, which is also what decides whether an escrow arrangement is worth anything to you. What does not depend on that negotiation: the hand-off phase is in the plan from the start rather than improvised under pressure, your data is exported in a platform-neutral format as well as ours and then certified destroyed to NIST SP 800-88, documentation, runbooks and architecture decision records are written as the work happens rather than assembled at the end, and there is a named handover contact for a defined window after the last day.
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.
- Phone
- (214) 723-2510
- Reply
- A person replies, not a sequence: within one business day, from someone who would be on the engagement.