Software Solutions
Software that ships and cannot be supported has not shipped.
The failure mode of custom software is not the build. It is the handover: a system that works on the day it is accepted, whose observability was never designed, whose failure modes were never discussed, and whose operating cost nobody modelled until the first invoice. Aevis argues about all three while the design is still cheap to change.
- Operability designed, not retrofitted
- Security practice inside the pipeline
- Handover with support, not at go-live
10
capability areas under one contract
01
organisation that both builds and runs
100%
of builds handed over with run-books
The challenge
What usually brings a software conversation to us.
Rarely a greenfield idea. Far more often a system that already exists and has become the constraint on everything around it.
A system nobody will change
Business-critical, still working, and unchangeable without a risk nobody will sign for. Every project that touches it gets re-scoped to route around it instead, at increasing cost.
A process no product fits
The packaged options each cover 70% and the remaining 30% is the part that differentiates the business. Configuration has been pushed past the point where it is cheaper than building.
Integration performed by people
Systems that do not talk are reconciled by staff copying data between them. The error rate is accepted as a cost of doing business because the alternative was never scoped.
A delivery that ended at go-live
The build was accepted and the team dispersed. There is no run-book, no observability worth the name and no route to a fix, so the first production incident becomes a procurement exercise.
An operating cost nobody modelled
The design decisions that determine hosting and licence cost were made during the build with no one in the room who would pay for them. The bill arrives in the second quarter of operation.
Releases that are feared
Testing is manual and partial, so each release carries unknown regression risk. The response has been to release less often, which makes every release larger and more dangerous.
Data the business cannot reach
The information exists across several systems and can only be assembled by hand, so decisions are made on a monthly extract that is already out of date when it is read.
Security applied at the end
A penetration test late in delivery produces findings that require design changes, at the point in the schedule where design changes are most expensive and least likely to be made.
The service
Built to be operated.
Aevis designs and builds the software the business needs and the market does not sell: internal platforms, customer-facing applications, the integration layer between systems that were never meant to meet, and the modernisation of applications that still work but can no longer be changed safely.
What separates this practice from a pure delivery shop is that the same organisation runs estates. Observability, release process, failure modes and the cost of operating a design are argued about while the design is still cheap to change, because the people who would be woken up by it are in the room. That is an uncomfortable conversation to have in week three and a considerably more expensive one to have in month fourteen.
Delivery ends with a handover that includes run-books, architecture records and an agreed support position — not at the acceptance signature. Where you want us to keep operating what we built, that is application managed services under the same governance; where you do not, the documentation is written so that somebody else genuinely can.
- Engagement type
- Fixed-scope project, dedicated build team, or modernisation programme
- Coverage
- Custom build, integration, modernisation, data, QA
- Working pattern
- Distributed delivery with agreed time-zone overlap
- Governance
- Demonstrable increments, architecture decisions recorded
Capabilities
Core capabilities.
Ten capability areas, contracted together or individually. Each one is a delivery responsibility with a named owner, not a technology we list because we have heard of it.
Custom software development
Systems built to a business process that no packaged product fits — where the part that does not fit is the part that differentiates the business.
- Discovery that establishes whether building is genuinely the right answer
- Architecture decisions recorded with their trade-offs, not only their outcome
- Demonstrable increments rather than status reported against a plan
- Operability — logging, health, failure modes — designed in, not retrofitted
Web and mobile applications
Customer and workforce applications across web and native platforms, built to the accessibility and performance standards the audience actually needs.
- Responsive web applications with performance budgets set before build
- Native and cross-platform mobile with a defined store-release process
- Accessibility to an agreed standard, tested rather than asserted
- Offline and poor-connectivity behaviour designed where the audience needs it
Enterprise system integration
APIs, middleware and data flow between systems that were never designed to meet — the work that most often removes an entire manual process.
- Integration designed around the failure cases, not only the happy path
- Idempotency, retry and reconciliation as first-class requirements
- API design and versioning that does not break consumers on release
- Monitoring on the interfaces themselves, because that is where these fail
Application modernisation
Re-platforming and refactoring applications that work but can no longer be changed safely — incrementally, because a rewrite is the option with the worst record.
- Characterisation tests written before behaviour is changed
- Incremental strangulation rather than a parallel rewrite with a switchover date
- Dependency and runtime currency brought back inside vendor support
- The option of doing nothing costed honestly against the alternatives
Cloud migration
Moving workloads with the operating model and the cost position designed rather than assumed — the two things a lift-and-shift defers and then never revisits.
- Target operating cost modelled before the migration, not after
- Landing zone, identity and network design agreed with whoever will run it
- Migration sequenced by dependency with rollback defined per wave
- Post-migration optimisation scoped as work rather than left as an aspiration
Quality assurance and testing
Functional, regression, performance and automation testing as part of delivery, so release confidence comes from evidence rather than from how careful everyone feels.
- Automated regression built alongside the feature, not afterwards
- Performance tested against a stated target, not against "fast enough"
- Test data managed lawfully, including where production data cannot be used
- Release decisions made on evidence with a rehearsed rollback
Data engineering and reporting
Pipelines, warehousing and the reporting layer the business actually reads — built from the decisions it has to support rather than from the tables that exist.
- Reporting designed backwards from the decision it informs
- Pipelines with lineage, freshness and failure alerting as requirements
- A modelled layer between source systems and reports, so one change is one change
- Retention and residency handled as design constraints rather than as policy
Product design and user experience
Research, flows and interface design ahead of build rather than alongside it, because the cheapest change to a system is the one made before it is written.
- Research with the people who will actually use it, including the reluctant ones
- Flows and prototypes tested before any of it is built
- Design system and component library so the fifth screen costs less than the first
- Accessibility considered at design time, where it is nearly free
Secure development practice
Threat modelling, dependency and code review inside the pipeline — because findings raised by a penetration test late in delivery arrive when they cost the most.
- Threat modelling at design time against the actual data being handled
- Dependency, secret and static analysis running on every change
- Code review as a standard with defined criteria, not as a courtesy
- Independent testing supported and its findings tracked to closure
Application support and enhancement
Post-launch ownership under the same governance as the rest of the estate, for the clients who want the people who built it to keep running it.
- Support against defined severity and restoration targets
- Enhancement delivered on a cycle rather than as a series of change requests
- Dependency and runtime currency maintained rather than allowed to lapse
- Run-books kept current as the system changes, not written once at handover
Enterprise AI engineering
AI features that can be evaluated, not demonstrated.
Copilots, retrieval applications and workflow agents built into enterprise systems — with the evaluation, observability and guardrails that decide whether they can be run in production rather than shown in a pilot.
Enterprise copilots
Assistants built against approved internal knowledge and permissions, answering inside the systems people already work in.
Retrieval applications
Grounded, source-linked answers over the client’s own content, with the retrieval layer and its permissions designed as part of the build.
Governed workflow agents
Multi-step task execution bounded by policy, with approval gates, exception handling and rollback designed in from the start.
AI integrations
Model, vector and orchestration services wired into existing enterprise architecture and identity.
Model evaluation
Test sets, accuracy and regression criteria agreed before release, and re-run on every change.
Observability and guardrails
Logging, cost and latency monitoring, prompt-injection and data-exfiltration controls, and a defined fallback when the model is wrong.
What stays human
Release approval, risk acceptance and the decision to let an agent act without review are human decisions. Any action that writes to a production system of record is gated on an approval the application records.
How value is measured
- Evaluation pass rate against the agreed test set
- Grounded-answer and citation accuracy
- Task completion and human fallback rate
- Latency and cost per completed task
- Guardrail trigger rate
- Defect and rollback frequency after release
Entitlement
Model availability, data residency and commercial terms depend on the client’s chosen provider and subscription. Aevis builds against the provider the client selects and does not resell model capacity.
Outcomes
What changes for the business.
Operational changes rather than promises. Each one is visible at handover or in a delivery review, and each is stated as something that can be checked.
Software specified against the cost of running it
Hosting, licence and operational cost are modelled during design while the decisions driving them can still be changed, rather than discovered in the second quarter of operation.
Manual re-keying removed rather than reduced
Integration is designed around its failure cases, so the reconciliation work it replaces does not quietly reappear as a weekly exception process.
Legacy systems that can be changed again
Characterisation tests and incremental strangulation return a system to a state where a change is a change, without betting the business on a rewrite and a switchover date.
A supported handover, not an ending
Run-books, architecture records and an agreed support position are delivery outputs. The first production incident is an operational event rather than a procurement exercise.
Releases decided on evidence
Automated regression and a rehearsed rollback mean releases can be frequent and small, which is the only reliable way to make them boring.
Security findings that arrive cheaply
Threat modelling at design time and analysis in the pipeline surface issues while they are still design decisions rather than late-stage schedule problems.
Delivery
How an engagement runs.
The same eight stages every Aevis engagement uses. Two of them carry unusual weight here: assessment, which is where we establish whether building is the right answer at all, and transition, which is the handover this practice most often gets wrong industry-wide.
Discovery
The process as actually performed, the systems already involved, who the users are and what they currently do instead, and what has to be true for this to have been worth doing.
OutputProblem definition and a stated measure of success
Assessment
Whether to build, buy, configure or leave alone — costed honestly, including the option of doing nothing, and including the cases where a packaged product would serve you better than we would.
OutputBuild, buy or configure recommendation with each costed
Design
Architecture with its decisions recorded, user flows researched and prototyped, threat model against the data actually handled, and the operating cost of the design modelled before it is committed.
OutputArchitecture decision records, prototypes and a cost model
Build
Delivered in demonstrable increments with automated regression built alongside, secure-development checks running on every change, and observability implemented as a requirement rather than as a later story.
OutputWorking increments with tests and instrumentation
Transition
Acceptance against the criteria agreed at design, run-books and architecture records handed over, rollback rehearsed, and the support position agreed before go-live rather than after the first incident.
OutputAccepted release with run-books and an agreed support position
Operations
Where contracted, the system is supported against defined targets by a practice that runs estates — dependencies kept current, interfaces monitored, incidents investigated to cause.
OutputSupported system with dependency currency maintained
Governance
Delivery reviews against the measure of success stated at discovery, architecture decisions revisited when their assumptions change, and cost tracked against the model rather than against the budget.
OutputPeriodic delivery review and a maintained decision record
Continuous improvement
Enhancement delivered on a cycle, technical debt carried visibly with a cost attached, dependency and runtime currency maintained, and the design revisited where usage turned out differently from the research.
OutputTracked backlog and a visible technical-debt position
Engagement models
The same sequence, contracted three ways. The split of responsibility is written down before the service starts.
Fixed-scope project
A defined deliverable with agreed acceptance criteria and a written change path. Aevis holds delivery accountability. The shape for work with a genuine edge, where you want the risk of reaching it to sit with the supplier.
Dedicated build team
A standing team working to your priorities on a continuing product, with capacity flexed inside an agreed band. The shape where the work is ongoing and the backlog is yours to direct.
Modernisation programme
Incremental strangulation of an existing system over multiple phases, each with its own acceptance point, so value and risk reduction arrive before the end rather than at it.
Platforms
Platforms and technologies.
We work in the stack that fits the problem and that you can hire for afterwards. These are the categories and representative technologies we build in.
Application platforms
- .NET
- Java and Spring
- Node.js
- Python
Front end and mobile
- React
- Vue and Nuxt
- React Native
- Swift and Kotlin
Cloud and runtime
- Microsoft Azure
- Amazon Web Services
- Kubernetes
- Serverless functions
Data platforms
- PostgreSQL
- Microsoft SQL Server
- Databricks
- Snowflake
Integration and messaging
- REST and GraphQL APIs
- Azure Service Bus
- Apache Kafka
- MuleSoft
Engineering and delivery
- GitHub
- Azure DevOps
- Terraform
- GitHub Actions
Testing and quality
- Playwright
- Cypress
- k6
- SonarQube
Identity and access
- Microsoft Entra ID
- Auth0
- Okta
- OAuth 2.0 and OIDC
Industries
Where this work lands.
The same capability, constrained differently. What a regulated environment requires of a build is usually a design constraint rather than a later checklist.
Banking and Financial Services
Auditable change and segregation of duties inside the delivery pipeline itself, with data residency and retention treated as architecture rather than as configuration applied later.
Insurance
Policy, quotation and claims workflow built around rules that change frequently, with the rule layer designed to be changed by the business rather than by a release.
Healthcare and Life Sciences
Clinical and research systems with interoperability standards as requirements, and a validated change path where the software sits inside a regulated process.
Manufacturing and Automotive
Plant and quality reporting integrated with production systems, modernised incrementally because a shutdown is the one thing the programme cannot spend.
Hi-Tech and Semiconductor
Engineering-adjacent tooling and platform work at high change velocity, with intellectual-property handling agreed before any access is granted.
Consumer Goods and Retail
Customer-facing applications with performance budgets set against real device and network conditions, and load proven before the trading peak rather than during it.
Energy and Utilities
Field applications designed for intermittent connectivity, and integration with operational systems where safety constraints bound what software may be allowed to do.
IT, BPO and Professional Services
Multi-tenant platforms where per-client segregation is an architectural requirement, and reporting each client can be given without assembling it by hand.
Why Aevis
Why Aevis for software.
Service-specific differentiation. These are the reasons this practice is structured the way it is, not general company claims.
The people who run production are in the room
Observability, failure modes and operating cost are argued about during design because Aevis also operates estates. Those are cheap conversations in week three and expensive ones in month fourteen.
We will tell you not to build it
The assessment stage costs build, buy, configure and do-nothing honestly. A development partner whose assessment never concludes "buy the product" is not assessing; it is quoting.
Handover is a deliverable
Run-books, architecture decision records and an agreed support position are delivery outputs with acceptance attached, so the first production incident does not become a procurement exercise.
Incremental over rewrite
Characterisation tests and strangulation deliver risk reduction along the way. The parallel rewrite with a switchover date has the worst record in this industry and we will argue against it.
Security while it is still design
Threat modelling at design time and analysis in the pipeline mean findings arrive when they are design decisions, not when they are schedule problems three weeks before launch.
A stack you can hire for
Technology choices are made against what you will be able to recruit and support afterwards, not against what is most interesting to build in. That constraint is stated in the design record.
Technical debt carried visibly
Where we take a shortcut to meet a date, it goes on the backlog with a cost attached rather than into the codebase silently. You get to decide whether to pay it down.
Support is a choice, not a consequence
Ongoing operation is a separate line in the agreement, and the documentation is written so another supplier genuinely could take it. Being replaceable is what makes the recommendation trustworthy.
FAQ
Frequently asked questions.
Answers are written to the same discipline as the rest of the page: they describe what the service does and, where the honest answer is "no provider can", they say that instead.
How do we know we should build rather than buy?
The assessment stage exists to answer that, and it costs building, buying, configuring and doing nothing side by side. Most processes are better served by a product; the cases that genuinely warrant a build are where the part no product fits is the part that differentiates you. We would rather lose the build and be right about it.
Who owns the software you build?
You do. Intellectual property in bespoke deliverables transfers to you on the terms in the engagement agreement. Where the build incorporates open-source or third-party components, their licences and any obligations they carry are documented as part of handover rather than left to be discovered.
Our legacy system needs replacing. Can you rewrite it?
We can, and we will usually argue for not doing it that way. A parallel rewrite with a switchover date has the worst track record of any approach in this industry, and it is what both of the abandoned attempts we most often hear about had in common. Incremental strangulation delivers risk reduction along the way and does not require a moment when everything changes at once.
Can you deliver fixed price?
Where the work has a genuine edge, yes — that is the fixed-scope model, with acceptance criteria and a written change path agreed before pricing. Where the scope is genuinely still being discovered, a fixed price is either padded or is a dispute waiting to happen, and we will say so rather than quote one.
Who supports it after go-live?
Your choice, and it is a separate line in the agreement precisely so it stays a choice. We hand over run-books, architecture records and an agreed support position whether or not you retain us. If we have written the documentation properly, another supplier can pick it up — that is the test we hold it to.
Can you work with our existing development team?
Yes, and it is common. What matters is agreeing at the start who holds architectural decisions and what the definition of done is for both sides, because the failure mode of a blended team is two standards of finished coexisting until an integration point exposes the difference.
How do we avoid an operating cost surprise?
By modelling it during design, while the decisions that drive it can still be changed. The cost model is a design-stage output and is tracked against actuals afterwards. Most cost surprises are architecture decisions taken with nobody in the room who would pay for them.
Do you build to accessibility standards?
To an agreed standard, tested rather than asserted, and considered at design time where it is nearly free. Retrofitting accessibility into a built interface costs several times what designing for it costs, which is the practical argument regardless of what the legal one is in your jurisdiction.
Do you arrange penetration testing?
We support it and track findings to closure, and we work alongside your chosen independent tester. What we would rather avoid is testing being the first security activity in the project — threat modelling at design time and analysis in the pipeline mean the test confirms a position rather than discovering one.
How long will it take?
We give an indicative sequence at the end of assessment, once the shape of the work is known, and we would rather do that than name a duration in a first conversation. Where a date is genuinely fixed — a regulatory deadline, a trading peak — that becomes a design constraint and scope is shaped around it explicitly.
Software enquiry
Start with the problem, not the specification.
The most useful first conversation is not a requirements document. It is establishing what has to be true afterwards and what people currently do instead — because the honest answer is sometimes that you should buy a product.
- Response
- One working day, Monday to Friday