A build-or-buy answer
Tell us the process and the products you've already ruled out. We weigh them against GOV.UK's build and buy lists, set out below, and show you which lines on each list your situation matches, and which way that points.
Custom software development company in India
Build what you must, buy what you can — and plan for what comes next.
We help you decide whether to build custom software or configure a product you can buy, using the build and buy lists in GOV.UK's Technology Code of Practice, a public checklist written for UK government. If building fits, we build it. We also replace old systems your business still depends on.
- We tell you when buying fits
- Code ownership written into the contract
- Security review before launch
- GOV.UK Technology Code of Practice, point 11
- GOV.UK Managing legacy technology
- Azure Architecture Center, Strangler Fig pattern
- AWS Prescriptive Guidance, strangler fig pattern
- PostgreSQL Versioning Policy
In brief
- What it is
- Help deciding whether to build custom software or configure a product you can buy, and the build itself when building fits. It also covers replacing old systems people still use.
- Why it matters
- Neither answer ends your work. GOV.UK advises configuring a bought product (changing its settings) rather than modifying it, so the supplier keeps supporting it through new versions. A custom build is made of parts, such as the database and frameworks, and each part's publisher decides when its fixes stop.
- What you get
- A build-or-buy answer you can check against a public list. If building fits, software you own, reviewed by our security practice before launch.
What we do
Build it, buy it, or replace what you have.
Three ways we can help. Not sure which one fits? Start with a call and we'll suggest where to begin.
Custom software, when building fits
Software built around the way you work. Our security practice reviews each build before launch, and code ownership is written into the contract.
Replacing a system people still use
Legacy application modernization: we replace software your business still depends on, and work out with you whether replacing it piece by piece fits.
Building one product to sell to many customers adds a decision on how each customer's data is kept apart (tenancy): see SaaS development. For sign-in and roles, see web application development; for connecting systems, API development and integration.
The build-or-buy decision
Name the problem before you name the answer.
GOV.UK publishes one list of signs that building fits and another that buying fits. Your situation may tick items on both.
GOV.UK's Technology Code of Practice is written for UK government organizations. It does not bind a private business. We use it because it asks a plan to show how the build-or-buy decision was reached. Its point 11 asks for the user need or problem first, and for how the chosen technology answers it.
If you have no in-house technical team, point 11 describes buy-to-build: hiring a team or specialists to build the product. It still asks how the technology will be managed once it is built.
When point 11 says building fits
- Your process is unusual. What you need is unique or rare.
- The market is thin. Few capable suppliers can deliver what you need.
- Nothing on sale stretches far enough. Commercial products can't be scaled, adapted or integrated.
- You will keep changing it. You need to own the technology to keep modifying it.
- You can see it through. You have the capability and resources to manage the project.
When point 11 says buying fits
- A product does most of it. A commercial product meets most of the user needs.
- Set-up closes the gaps. Suppliers can configure settings or features to fit.
- It works almost as sold. Little customization or bespoke change is needed.
- Expert help is available. Specialist knowledge and support can be bought.
- Your team can look after it. Your organization can support what it buys.
When a product you can buy does most of what you need, we say so, even though it costs us the project. Our about page puts that in writing.
If you buy
Four things a bought product still leaves to you.
GOV.UK and Microsoft describe what stays with the organization that buys.
Trial it on a hard problem
Point 11 suggests considering a demonstration or smaller trial: one small but hard problem, plus a test of integration with the products you already run.
Configure rather than modify
Point 11 advises changing the product's settings, not the product, so supplier support survives new versions. It warns that modifications can make maintenance harder and restrict later upgrades or removal.
Keep your data and identities
For its own cloud services, Microsoft's shared responsibility model says: “For all cloud deployment types, you own your data and identities.” Identities are the user accounts and their access. Microsoft calls this illustrative guidance that changes no agreement with Microsoft.
Plan the whole lifecycle
Point 11 asks buyers to understand a product's lifecycle through to retirement. It suggests planning continuous improvement, to avoid creating technical debt (shortcuts that cost more to fix later) and legacy technology.
If you build
Every part of a custom build stops getting fixes when its publisher says so.
GOV.UK's Managing legacy technology guidance counts technology as legacy when it is end-of-life, unsupported or impossible to update. Most of our builds use React or Next.js, Node or Python, and PostgreSQL. Here is what each publisher says.
| Component | Publisher's rule | Where it is written |
|---|---|---|
| PostgreSQL | A final minor release (a small update), then the version is unsupported | PostgreSQL Versioning Policy |
| Node.js | Production should use only Active or Maintenance LTS (long-term support) releases | Node.js Previous Releases page |
| Python | Security fixes only, no new binaries (ready-to-install downloads), then frozen (no further changes) | Python Developer's Guide, Status key |
| Next.js | Maintenance LTS ships only critical and security fixes | Next.js Support Policy |
| React | Backported security fixes (fixes copied back to older versions); no support window stated | React Versioning Policy |
Legacy application modernization
Piece by piece or all at once: it depends on the system.
Microsoft and AWS call gradual replacement the strangler fig pattern: new parts take over piece by piece while the old system keeps running.
Replacing everything at once
Microsoft's Azure Architecture Center calls replacing a whole complex system difficult. AWS Prescriptive Guidance says migrating a monolith (one large application) in one operation introduces transformation risk and business disruption.
Where gradual replacement fits
Microsoft says to use the pattern for a gradual back-end migration, especially where replacing large systems or complex features introduces risk. It lists four cases where the pattern might not be suitable. One is legacy source code you cannot access and change.
GOV.UK's reasons and options
GOV.UK's reasons to migrate include lost supplier support and an expiring technology contract. Its strategies can include retain, retire, re-host (move it as it is to new hosting), repurchase and re-platform (move it to a new platform with small changes).
Scoped separately. When new software has to connect to your ERP or another system of record (the main system your business records live in), we scope that integration separately. Keeping that system and building beside it is covered on enterprise software development.
FAQ
Questions about building, buying and replacing.
Contracts, upgrades and which rules apply to you. For anything else, ask us directly.
Start from the need. Point 11 of GOV.UK's Technology Code of Practice, written for UK government, lists when building fits and when buying fits. Building fits a rare need, few capable suppliers or products that cannot be adapted. Buying fits when a product you can configure meets most needs. If a product already does most of the job, SecWiz says so.
Configuration, data and identities. Point 11 of GOV.UK's Technology Code of Practice advises configuring rather than modifying, to keep product support through new versions. Point 3 warns that customizing can make future updates and security patches hard to apply. For its own cloud services, Microsoft's shared responsibility model leaves data and identities with the customer, as illustrative guidance.
Nothing breaks on the day. The software keeps running without bug or security fixes, and GOV.UK's Managing legacy technology guidance would class the unsupported component as legacy. Upgrades need care too: PostgreSQL's versioning policy says major versions make changes that stop the data directory staying backward compatible, so a new major version cannot simply reuse an older version's data files. And dates can move: the Python Developer's Guide says release managers can adjust specific dates.
It depends on the system. Microsoft's Azure Architecture Center recommends replacing it gradually (its Strangler Fig pattern) when replacing a large system in one go adds risk and the old system can keep running meanwhile. The pattern may not suit a legacy system whose source code you cannot access. For a small application with simple refactoring, AWS Prescriptive Guidance says a rewrite might be more efficient.
No. The Policy on Adoption of Open Source Software for Government of India, issued by DeitY and hosted by MeitY, covers government organizations under the Central Government and State Governments that choose to adopt it, excluding those offering commercial services. MeitY's Common Application Software guidance also addresses government organizations, not private companies.
Point 11 of GOV.UK's Technology Code of Practice says contracts must state clearly who owns the intellectual property in a technology service, including the software code and the business rules handling information between user interfaces and stored data. The clause suits a private contract as well. With SecWiz, you own the code, and ownership is written into the contract, as our about page sets out.
Let's talk
Tell us what you looked at buying.
Describe the process, the products you have already ruled out, and why each one failed. Project work is delivered remotely from India during business hours. We reply within one working day.