Technology built around the way your business works.
Projects stall on people, not on ideas. Novatek adds engineering capacity with a defined delivery process, testing before release and a support model agreed before anything goes live.
A roadmap that is limited by capacity, not clarity.
You know what needs building. The integration, the internal tool, the rebuild of the thing everybody complains about. It sits on the roadmap because there is nobody free.
Novatek is a practical technology partner rather than an innovation consultancy. We take defined work, deliver it against a plan, test it properly and support it afterwards.
What Novatek builds and maintains.
A focused set of services, each with a defined delivery process and a support model agreed before launch.
- Web development
- Marketing sites, landing pages and content platforms built for speed, accessibility and search.
- Web applications
- Internal tools, portals and dashboards that replace the spreadsheet a team has outgrown.
- Custom software
- Applications built to a specific operational workflow rather than bent out of an off-the-shelf product.
- API integrations
- Connecting the systems that currently need a person to copy data between them.
- QA & testing
- Test planning, functional and regression testing, defect tracking and release verification.
- Application maintenance
- Ongoing fixes, dependency updates, small enhancements and performance work.
- Technical support
- Tier-1 and defined tier-2 application support with agreed response targets.
- Cloud & infrastructure assistance
- Environment setup, deployment pipelines and monitoring support.
- Technical documentation
- The architecture notes, runbooks and handover documents projects usually skip.
Stack fit is confirmed at scoping — we will tell you plainly if your technology is outside what our team runs well.
Every engagement answers the same six questions.
Before a line of code is written, both sides should agree on the problem, the solution, how it is tested and who supports it afterwards.
Problem
What is broken or missing today, who it affects, and what it costs to leave alone.
Solution
What will be built, what is deliberately out of scope, and what "done" means in testable terms.
Technologies
What it is built with and why — including how it fits the stack you already run.
Development process
Sprint cadence, environments, code review, branching and how you see progress.
Security
How credentials, data and access are handled during and after development.
QA & support
How it is tested before release and who responds when something breaks at 2am.
Tested before it ships. Handled carefully throughout.
Quality assurance is a stage in the plan with its own time and its own owner — not whatever is left at the end of the sprint.
- Written test plans derived from acceptance criteria, not from memory.
- Functional testing on every change, before it reaches your review environment.
- Regression testing before release, so a fix does not quietly break something else.
- Defects in your tracker, visible to you as they are found rather than summarised later.
- Credential handling through your secret management, never in code, chat or documents.
- Environment separation so production data is not used for development or testing.
What happens after go-live.
Most of a system's life is after launch. The support terms are agreed before handover, not negotiated during an incident.
Critical
Service unavailable or data at risk. Response target and escalation path agreed per engagement.
High
Major function broken with no workaround. Fix targeted within the agreed window.
Medium
Function impaired but workable. Scheduled into the next maintenance cycle.
Low
Cosmetic or minor. Batched into planned releases.
Targets per severity level are contractual, agreed before handover so there is no gap between “delivered” and “supported”.
What we report on delivery.
Delivery visibility means you should never have to ask how the project is going.
| Metric | What it tells you | Reported |
|---|---|---|
| Delivery against plan | Whether committed scope is landing in the committed sprint. | Per sprint |
| Defect density | Defects found per unit of delivered work. | Per sprint and per release |
| Defect escape rate | Defects found after release rather than in QA. | Monthly |
| Cycle time | How long work takes from start to production. | Per sprint |
| Support response time | Time to first response by severity level. | Weekly |
| Release stability | Rollbacks and post-release incidents. | Per release |
Reported per sprint and per release, against the plan you agreed at the start of it. See how reporting is structured.
How delivery is actually controlled.
The documents themselves, not a description of them. Read them before you speak to us.
Sample reporting pack
A full week of real reporting structure — volumes, SLA, drivers, quality, actions.
Read itQuality scorecard
Six weighted criteria, scoring bands and what each one triggers.
Read itA worked SOP
Nine steps and six documented exceptions, at working detail.
Read itTransition plan
Five tranches with entry conditions and rollback triggers.
Read itQuestions about technical delivery
If the answer you need is not here, ask us directly — you will get a specific answer rather than a brochure.
Both models exist. An extended team works to your backlog, your ceremonies and your definition of done. A managed project has a Novatek delivery owner, a defined scope and an agreed acceptance process. We recommend which fits at scoping.
A written test plan against the acceptance criteria, functional testing on every change, regression testing before release, and defect tracking in your issue tracker so the state is visible to you rather than reported to you.
You do. Contract terms confirm ownership of code, designs and documentation produced for your engagement, along with confidentiality obligations that apply to every person on the team.
Application support is a defined service with its own response targets, not an assumption. Scope, hours and severity definitions are agreed before handover so there is no gap between "delivered" and "supported".
We publish a curated stack rather than a list of everything, so you can tell quickly whether we are a genuine fit — and we will say so if we are not.
What is stuck on your roadmap?
Describe the project that keeps getting deferred. We will scope it, tell you plainly whether we are the right fit, and set out how it would be delivered and supported afterwards.