Engineering services · Custom software
Custom Software Development
Software built around the way your business works.
We design and develop custom software around your business processes, bringing your teams, data, and tools together in a system that can grow with you.
What this service is
Who it's for, and what it fixes.
Custom software is worth building when the way your business works is part of why customers choose you, and the tools on the market force you to work like everyone else. It replaces the spreadsheet that five people edit, the copy-paste between three systems, and the steps that live only in one person's head.
We build business systems the same way we build our own products: start from the job someone does all day, model the records and the rules properly, and put access control on the server from the first screen. You get software your team can trust with real work, and a codebase another team could pick up tomorrow.
Operations-heavy businesses
Orders, jobs, inspections or approvals that move through several people and need a record of who did what.
Teams that outgrew spreadsheets
The sheet works until two people edit it at once, a formula breaks, or someone needs to see only their own rows.
Companies with an ageing internal system
Software that still runs the business but that nobody wants to change, because nobody fully understands it any more.
Businesses joining up their tools
Sales, billing, stock and support each in a different product, with people retyping the same customer five times.
Problems it solves
- The same data is typed into several tools, and they disagree
- Work stalls because nobody can see where a job is or who has it
- Everyone can see everything, because the tool has no real roles
- Reports take a day of exporting and fixing spreadsheets
- A key process depends on one person and a macro
What's included
The deliverables.
What a typical engagement produces. Discovery decides which of these your first release needs.
Process and data model
A written map of the workflow, the records it touches and the rules between them, agreed with the people who do the work before anything is built.
The application
A web application for your team, built around your steps and your words, with the screens each role actually needs and nothing else.
Roles and permissions
Who can see, change and approve what, enforced on the server for every request, with an audit trail of the actions that matter.
Integrations
Connections to the tools you keep, such as accounting, email, payments or an existing database, through their APIs, with retries and clear errors when the other side is down.
Reports and exports
The views and exports your managers need, built on the same data the team works in, so the numbers match.
Data migration
Your existing records moved in, cleaned and checked against the source, with a dry run before the real cut-over.
How an engagement runs
From first call to running software.
Five phases, each ending in something you can see and approve. The detail, and what we need from you at each step, is on how we work with you.
- 01
Discovery 1–2 weeks
We sit with the people who do the work, map the process as it really runs, list the records and rules, and agree what the first release must do. You get a written scope, a timeline and a fixed next step.
- 02
Design 1–3 weeks
Clickable screens for the main journeys, reviewed with real users, plus the data model and the integration plan. Changes are cheap here, so this is where we argue.
- 03
Build 6–12 weeks
Two-week cycles, each ending in a working build you can try. You see progress on real screens, not status reports, and priorities can change between cycles.
- 04
Launch 1–2 weeks
Data migrated, people trained, the old process run in parallel where that is safer, then the switch. We are on hand for the first weeks of real use.
- 05
Support Ongoing, if you want it
Fixes, small improvements and new features under a support arrangement, or a full handover to your own team with a walkthrough of the code.
Technology approach
Plain, proven, and yours to keep.
Mostly the stack behind the Varynt products, chosen per project. Read how we build.
- React
- TypeScript
- Java
- Spring Boot
- PostgreSQL
- Kafka
- Docker
- Front end
- React and TypeScript for the screens: fast, accessible, and easy to hire for. Pages work by keyboard and on a phone.
- Back end
- Java with Spring Boot for the business logic and APIs, the same foundation our own products run on. It is dull in the best way: well understood and long-lived.
- Data
- PostgreSQL for the records, with versioned migrations so every change to the database is reviewed and repeatable. Events between systems go through Kafka when the volume or the number of consumers calls for it.
- Sign-in
- Standard sign-in over OIDC, so your system can join the single sign-on you already use, with two-step sign-in available.
What you receive
Ownership, documentation, handover.
- The full source code in a repository you own, with its history, from the first week
- A written handover: architecture overview, how to run, build and release it, and the decisions taken and why
- Credentials, keys and accounts created in your name, never ours
- The automated test suites and the build pipeline, so anyone can keep shipping it
- A user guide for each role and a short admin guide
- A migration report showing what was moved and what was checked
Typical timelines
Ranges, not promises.
- One workflow tool
- 6–10 weeks
- A single process for one team, such as approvals or job tracking, with one or two integrations.
- A business system
- 3–6 months
- Several connected workflows and roles, reporting, and a data migration from existing tools.
- Replacing a legacy system
- 6 months and more, in stages
- Moved one module at a time, with the old and new running side by side until each part is proven.
Every project is quoted for its own scope after discovery; prices are not published.
Security and quality
The practices we use on our own products.
Varynt runs four products for paying customers. Client work gets the same habits. See trust and security.
- Every important action recorded in an audit log: who, what and when
- A staging copy of the system for you to try each release before it reaches your team
- Access is checked on the server for every request; hiding a button is never the control
- Code review on every change, and automated tests that run before anything is released
- Test suites run in more than one order, so a test that only passes by luck is caught
- Before a release changes a database, it is backed up and the backup is restored and checked
- Secrets live outside the code, and dependencies are kept current
Should we build custom software or buy an off-the-shelf product?
Buy when a product fits about four-fifths of your process and the rest can change. Build when the way you work is a real advantage, when you are paying for several tools that still do not join up, or when the data and rules are specific to your business. We will tell you in discovery if buying is the better answer.
Do we own the code?
Yes. The code lives in a repository in your name from the start, and the intellectual property is yours under the agreement. Accounts and keys are created in your name too.
Can you work with our existing system instead of replacing it?
Often that is the better plan. We can build around an existing system through its API or database, replace it one part at a time, or extend it, depending on its condition. We look at the code and the data before recommending one.
How do you estimate the timeline before the details are known?
We give a range after the first call and a firm plan after discovery, once the workflow and the integrations are understood. The plan is in cycles, so you can see early whether it is on track.
What happens if our requirements change during the build?
They usually do, and the two-week cycles allow for it. Changes go into the list for a coming cycle; anything that moves the timeline or the scope is agreed with you in writing first.
Who maintains the software after launch?
Either us, under a support arrangement with agreed response times, or your own team after a handover. The documentation and tests are written so either works.
Related
Services and products that fit alongside.
Other services: AI chatbots · AI agents · Mobile apps · LLM applications · SaaS products · Cloud and DevOps · MVPs for startups
Get in touch
Tell us how the work runs today.
A short call about the process and the tools involved. You get an honest view of build versus buy, and a scope and timeline if building is right.