How we work with you
From the first call to software you own.
Five phases, each ending in something you can see and approve. You get a demo every two weeks, a written update every week, and the code in your name from day one.
The phases
What happens, what you do, what you receive.
Durations are typical ranges. You get a firm timeline at the end of discovery, for your scope.
- 01
Discovery
1–2 weeks
We start with a call, then spend time with the people who will use the software. The aim is to understand the job, the data and the rules well enough to say what the first release must do, and what can wait.
What happens
- A first call about the goal, the users and the deadline that matters
- Working sessions with the people who do the job today
- A look at any existing system, data or code the project touches
- Risks named early: integrations, data quality, compliance
What you do
- Name one decision-maker and give us an hour or two of each key user
- Share access to existing tools, sample data and documents
What you receive
- A written scope for the first release, and what is left for later
- A timeline in cycles, a fixed quote for the next step, and the risks
- 02
Design
1–3 weeks
Before any production code, the main journeys become clickable screens that your users try, and the data model and integrations are written down. Changing a design costs hours; changing built software costs weeks.
What happens
- Clickable designs for the main journeys, reviewed with real users
- The data model, roles and permissions written down
- The architecture and integration plan, with the trade-offs explained
What you do
- Review the designs with the people who will use them
- Approve the design and the plan before the build starts
What you receive
- Approved designs, the data model and a short architecture document
- 03
Build
Usually 4–16 weeks
The software is built in short cycles. Each one ends with a demo of working software on a staging copy you can try yourself, and a plan for the next cycle that you help prioritise.
What happens
- Two-week cycles, each with a demo of working software
- Code review and automated tests on every change
- A staging copy you can use between demos
- A written update every week: done, next, and anything blocked
What you do
- Come to the demo, try the staging copy and give feedback
- Answer questions within a day or two, so nothing stalls
What you receive
- Working software every cycle, in a repository you own from day one
- 04
Launch
1–2 weeks
Launch is planned like a feature, not a deadline. Data is migrated with a rehearsal first, people are trained, and the release has a way back if something goes wrong.
What happens
- A rehearsed data migration, checked against the source
- Training for each role, and a short guide for each
- A release plan with a rollback step, then the switch
- Close watch of errors and use in the first weeks
What you do
- Plan the switch-over date with your team
- Sign off the release once acceptance checks pass
What you receive
- The live system, user and admin guides, and the handover documents
- 05
Support
Ongoing, as you need
After launch you choose: an ongoing arrangement where we fix, improve and extend the software, or a full handover to your own team with a walkthrough of the code and the release process.
What happens
- Fixes and small improvements under agreed response times
- Regular updates to dependencies and security patches
- New features planned in the same cycles as the build
What you do
- Report issues through one agreed channel
- Review the plan for the next improvements every month or quarter
What you receive
- A maintained system, or a team of your own that can run it
Working together
How we keep a project visible.
The same habits on every engagement, whichever service it is.
Communication rhythm
- One named lead on our side and one on yours
- A written update every week: done, next, and anything blocked
- A shared channel for quick questions between updates
- Decisions recorded in writing, so nobody has to remember a call
Demos you can touch
- A demo at the end of every two-week cycle, of working software
- A staging copy you can use between demos, with realistic data
- Priorities for the next cycle agreed at each demo
- Nothing is called done until you have seen it work
Code ownership and handover
- The repository is in your name from the first week
- Accounts, keys and domains are created in your name, never ours
- Architecture notes, run and release guides kept current as we go
- A handover walkthrough for your team whenever you want it
Quality and security gates
- Code review and automated tests on every change before it merges
- Access checked on the server for every request
- Before a release changes a database, a backup is restored and checked
- Every release has a written way back
What we need from you
- A clear point of contact who can answer questions and give feedback each cycle
- Access to any existing systems, accounts, or codebases the project touches
- Honest input on priorities and constraints: budget, timeline, must-haves
Ways to engage
Three ways to work with us.
Every engagement is quoted for its own scope after discovery. Prices are not published.
A defined project
You know what you need built and when it is needed.
- Fixed scope for the first release, agreed after discovery
- A timeline in two-week cycles, with a demo at the end of each
- Changes go into later cycles, agreed in writing when they move the plan
An ongoing team
You have a product or system that keeps growing.
- A small team that works with you month after month
- A rolling plan reviewed with you every month or quarter
- The same practices, demos and handover documents as a project
An MVP
You need to learn whether an idea works, quickly.
- The smallest version that real users can try, in weeks
- A short list of what the MVP must prove, agreed up front
- A codebase built to grow if the idea works, not thrown away
How long is discovery, and is it a separate engagement?
Usually one to two weeks. It can be a short engagement of its own, so you get a written scope, a timeline and a fixed quote for the next step before committing to the build. If you decide not to go ahead, the scope document is still yours.
How much of our team's time does a project need?
Plan for one decision-maker who can answer questions within a day or two and come to a demo every two weeks, plus an hour or two of each key user's time in discovery and design. More involvement speeds things up; less slows them down, never stops them.
What do we see between demos?
A written update every week, and a staging copy of the software that you can use at any time. You never have to wait for the end of a cycle to see where things stand.
When do we get the code?
From the first week. The repository is in your name and you can read every change as it is made. At the end, the handover adds the guides to run, build and release it.
What happens if we need to change direction mid-project?
The two-week cycles are designed for it. New priorities go into the next cycle. If a change moves the timeline or the scope, we write down the effect and agree it with you before it happens.
Can we start with an MVP and move to an ongoing team later?
Yes, and that is a common path. The MVP is built on the same foundations as a full product, so the team that built it can carry on without a rewrite.
Who will we actually work with?
The engineers who build and run the Varynt products. The person leading your project is involved from discovery to handover, so nothing is lost between a sales team and a delivery team.
Engineering services
What this process builds.
The practices behind it are on how we build and trust and security.
Get in touch
Start with a short call.
Tell us what you want to build. We reply with the questions that matter, then a scope, a timeline and a fixed next step before any work starts.