01
Process walkthrough
We sit with the people doing the work and follow the process end to end: the sheet, the thread, the exports, the workarounds nobody wrote down.
Approach
Start narrow, ship early, stay for the long run.
Operational software is never finished, because the operation keeps changing. The way we work is built around that fact rather than around a fixed statement of work.
Before any code
The first two weeks, concretely
Nothing is built until we both know what is being built and what it costs. Four things happen first, and each one produces something you can hold.
02
Research and mockup
We go away and work: a mockup of the tool, a workflow diagram, the technical approach, and a list of the questions the research raised.
03
Plan, scope, and price
We agree on the design, what is in the first build and what is deliberately left out, the schedule, and the price in writing, before anyone commits.
04
Work begins
Building starts against the plan we both signed off on, with the check-in rhythm that suits how closely you want to be involved.
The walkthrough and research stage is a paid, fixed-fee engagement.
Fixed fee, quoted before we start. Whatever comes out of it — the diagram, the mockup, the recommendation — is yours to act on, with us or with anyone else.
How an engagement runs
- 01 · START
Start with one process
We pick the one that costs the most hours, not the one that is easiest to describe. Scoped small enough to be in use quickly and important enough to be worth doing.
- 02 · EARLY
Put a working tool in front of people
Your team runs a real week through it and tells us what is wrong. Real use is the only reliable specification; a demo environment never finds what a Tuesday finds.
- 03 · GROW
Widen it as it earns its place
Each addition follows evidence from the last one, so scope grows for a reason. Practice Edge went from one clinic's tracking sheet to a product this way.
- 04 · ONGOING
Stay on for the long run
Maintenance, changes, and the next improvement, from someone who already knows your system. The check-in cadence is set per client: weekly when a build is live, lighter when things are steady.
Due diligence
The questions your IT lead will ask
Working with a small partner raises fair questions about ownership and continuity. Here are the answers before you have to ask.
Who owns the code?
You do, 100%, from the first commit. Nothing about the arrangement depends on you not owning what you paid for.
Where does it live?
Source is kept in Orbitech's GitHub during the engagement. Deployment goes wherever the project calls for it: Vercel, AWS, Railway, GCP, or Azure.
What if we part ways?
If the engagement ends, for any reason, we work with you and your new vendor on the transfer. No hostage-taking, no exit fee, no rebuild required.
How fast do you respond?
Within the hour during working hours. You are messaging the person who built the system, not a support queue that has to look up your account.
What this is not
- Not an offshore dev shop billing against a ticket queue.
- Not a body shop placing contractors inside your team.
- Not an enterprise consultancy with a discovery phase longer than the build.
- Not a platform you have to bend your process to fit.
What you can expect
- The person who builds it is the person you talk to.
- An honest answer when software is not the right fix.
- Scope and price agreed in writing before work starts.
- Plain language in writing, not status theatre.