Three ways to work with us.

The survey is for clients who want a comprehensive, clinical snapshot of their software systems, processes, and third-party tools in order to evaluate their readiness for outcomes. Some examples of these outcomes: moving to another cloud provider, cost-cutting, AI integrations, and dynamic usage scaling. It is a fixed-price engagement: we read your code, your data model, your deploy story, and the three or four critical paths that keep your business running, and we hand you a written document that says — plainly — where the system is strong, where it's brittle, what we'd fix first, and what we'd leave alone.

What you get

A thorough, organized report of your system covering architecture, data, deploys, scaling, and cost as one cohesive document, and applying to them any KPIs or goals your team has. Alongside it: current-state architecture diagrams (your system as it's actually deployed, drawn next to your system as your docs and IaC describe it), a services inventory of every third-party system the application actually touches, a prioritized roadmap, and more depending on your business requirements. If you have a unique analysis request, we're happy to accomodate.

We don't just tell you the what, but why. Every claim in every document traces back to specific evidence — a file in your repo, a cloud API response, a git commit, a CI run, a billing line. The evidence index and the full record of every read we did against your systems ship alongside the deliverables, so anything in the report can be reproduced or audited later by someone who wasn't on the call. The whole package renders as PDF, DOCX (so your team can comment and edit it in Word or Google Docs), and HTML.

After we draft the report, we walk it through on a call with you and whoever else needs to be in the room. The prioritized roadmap is a document another engineer — ours, yours, or someone else's — can pick up and execute against. The deliverables stay yours. Nothing about the survey is locked to working with us afterward. If you take our documents, hand them to your existing team, and never call us again, that's a successful survey by our definition.

What we look for

The survey reads your system from the cloud control plane down to the data layer, against what your docs and intentions say it should be. We have opinions about each of these, and the deliverable will name them out loud.

• The system as deployed vs. the system as documented. Cloud APIs and IaC say one thing. Your README and ADRs say another. The gap between them is usually where the surprises live — we draw both, side by side.
• Every third-party service your application actually touches. Active services in HEAD, services removed in the last twelve months, services proposed in ADRs or TODOs but never built. Generated from the code and git history, not from anyone's memory.
• The data layer's three-year horizon. Schemas, indexes, slow queries, hot tables, parameter-group anomalies. Most SMB systems are fine until year three — we read your schema and your slowest queries before we read your application code.
• The path from commit to production. DORA metrics with sample sizes and confidence intervals (a point estimate from twelve PRs is noise, and we'll say so). Where deploys go quiet, where rollbacks pile up, which step everyone has learned to work around.
• Scaling risk and vulnerability surface. Static analysis on the application code, dependency CVEs, secrets in git history, container and IaC checks. Findings get filtered against your real growth profile — issues at scales you won't reach are kept separate from the ones that will hit you next year.
• Cloud cost. Idle resources, oversized instances, unattached volumes. Savings figures get a conservative and an aggressive end, and every range cites the billing line it came from.
• The cloud/fleet decision. Serverless makes sense for some workloads and is a budget bomb for others. VM fleets are the right answer more often than the industry admits. We'll tell you which one you have, with numbers.
• The roadmap items that have been "next quarter" for six quarters. There is always a reason. We tell you whether the reason is technical or organizational, and which of the two is actually cheaper to fix.

Who it's for

Founders and decision-makers at startups and small-and-mid-sized businesses looking to plan future steps or evaluate your software capital.

Fractional engagements are for when ongoing expertise and development is needed, but it's most practical or feasible for such expertise to be an outside expert as opposed to full-time in-house. We come in as the senior engineering force and serve you either partially or in-full as you need. We provide everything from architecting to business advice to development and product consulting for our clients. As needed, we leverage our partner network to bring in experts to further enhance the project.

What you get

A named principal responsible for your software needs, capable of serving as your all-in-one architect, engineering manager, developer, consultant, and product lead.

Who it's for

1. Non-technical companies building or maintaining mission-critical software systems in need of competant management and direction.
2. Teams undergoing a period of change (growth, implementing SOC processes, acquisition, etc.) and in need of temporary leadership.
3. Early stage companies and startups where expertise is required but it doesn't yet make financial sense to bring an expert on full-time.

Don't fall behind neglecting modernization when things are changing so fast in the industry. Modernization is the necessary work of taking a system that runs your business and rebuilding the parts of it that hold you back, without ever taking the rest of it offline. This work includes database migrations, API extractions, and developer workflow integrations using AI. Think your framework upgrades that have been pushed to next quarter for the last six quarters.

What you get

A project beginning with a written proposal of services, fixed milestones, and a real handoff at the end. We work inside your repository, against your existing team's review process, with feature flags and incremental cutovers wherever there's a system already in production. Every change lands behind a verification step. Every milestone is something you could ship to production today if we walked away at that point.

Code that ships includes tests, runbooks, and documentation written to last. Collaboration and pedagogy are two of our four core values, so we treat the readability of our changes, and the knowledge transfer that goes with it, as part of the deliverable.

Who it's for

Businesses with a system in production that's still load-bearing but is starting to slow you down — hires take too long to onboard, every feature ships with a side of regression, the framework is two majors behind, the database is one wrong query from a stall. Some examples: a Rails 4 monolith that needs to be a Rails 7 monolith, a 2017-era React + REST app that wants to be Next.js + GraphQL, a monolithic REST architecture that needs to scale dynamically for fluctuating traffic.