How We Work
Tests first. One slice at a time.
Engagement model
Hourly, time and materials. You work with two to three senior engineers, all US-based, all of whom have shipped production software on the stack you are leaving and the stack you are moving to. There is no account layer between you and them; one of them is named as the engagement lead and is your single point of contact. Scope is agreed through an initial conversation before work starts, revisited as the code teaches us more, and reported against, so you always know where the hours went. Engagements run as scoped projects or as staff augmentation inside your team.
Most engagements begin with the assessment, unless you already have an equivalent harness and map, in which case we will review it and start from there.
How we use AI
We use AI tooling heavily and specifically:
- Reading and mapping large codebases, including VB6 and FoxPro syntax that most tools ignore.
- Drafting characterization tests in bulk from recorded behavior.
- Transcribing business rules from old code into new, under review.
- Producing first drafts of documentation and runbooks.
We do not use it to convert whole codebases unattended, to make architecture decisions, or to decide which behaviors are contracts and which are bugs. Those are engineering judgments and they are made by engineers. Every line that ships is reviewed by a human who is accountable for it.
Your source code is not used to train any model. We use commercial model providers under agreements that exclude training on customer data, or, where you require it, models hosted in your own environment.
Typical timeline
Every system is different; a typical engagement runs like this.
| Step | Typical duration | Ends with |
|---|---|---|
| Assessment | About 2 weeks | Map, harness, one migrated module, a written plan |
| First slice | 6 to 12 weeks | First slice live, rollback tested |
| Further slices | 6 to 12 weeks each | Next slice; data moved when its owner slice moves |
| Ongoing support | As needed | Harness kept green, patches handled, next slice scoped |
Most systems on these stacks are fully migrated in three to eight slices. Some should not be fully migrated; the plan will say so, and an agent access layer may be the better end state for parts of the system.
Deliverables
Everything goes into a repository you own from day one: source, tests, infrastructure definitions, the dependency map, runbooks. There is no proprietary framework in the output. If we disappeared, your team or any competent .NET shop could carry on from the repository and the plan.
Security and compliance posture
- Read-only access for the assessment; write access only to the new repository and environments you provision.
- Work is done on company-managed, encrypted devices; no source leaves the agreed environments.
- Mutual NDA before any access. We will sign your data-processing terms.
- No offshore access to your source or data, by policy.
- Production data is not copied to our environments. Characterization tests run against masked or synthetic data you approve, or inside your network.
- For regulated environments (healthcare, finance, government contractors) we will work inside your VDI or bastion and accept the slower pace that implies.
What we ask of you
A developer or analyst who knows the system, for two to four hours a week. A decision-maker who can approve a slice and a cutover. Honest answers about what the system does that nobody is proud of; that is where the characterization tests need to go first.