How We Build Software Faster and Safer: Inside Keystone, Our Reusable Microservices Pack

If you outsource software, you have almost certainly paid for the same thing more than once. Every new vendor, and often every new project with the same vendor, starts from a blank page: user accounts, permissions, approvals, payments, logging, audit trails — the unglamorous machinery that every serious system needs. It gets designed again, built again, and debugged again, on your budget and your timeline.

This is the quiet tax in most outsourced software, and the cure is reusable software components: machinery built once, hardened in production, and assembled into every build that follows. Skipping them is slow and expensive — first-time code, written under deadline, is where a large share of bugs and missed edge cases come from.

This post is for decision makers who buy technology rather than build it in-house, and who want to understand how a partner builds, not just what they promise. It explains the design approach we use to avoid that tax — a reusable microservices pack we call Keystone — and, more usefully, how you can judge whether any partner you are evaluating works this way.

The short answer: We do not rebuild common machinery on every project. Approvals, audit logging, access control, payments and business-rule policies live in a reusable pack of production-hardened services. A new product assembles them and spends its engineering effort on what is genuinely unique to the client. Across our own custom projects, reusing this machinery has saved around 18% of total build effort — code, testing and documentation included — while carrying quality, cost and audit controls from the first day rather than the last.

Why outsourced software is slower and buggier than it should be

Most outsourced builds fail on cost and quality for a structural reason, not a talent one. When every project begins from nothing, three things follow.

You pay to rebuild the foundations. A meaningful portion of any build is foundational plumbing that has nothing to do with your actual product. Rebuilding it each time is pure cost with no differentiation to show for it.

Quality is inconsistent. Foundational code written fresh under deadline is exactly where reliability problems hide — a payment that charges twice on a retry, an action with no audit record, a permission check that was never quite finished. These are solved problems, but only if you are reusing the solution.

Controls arrive last, if at all. Audit trails, approval gates and access control are treated as features to add later. They get squeezed when timelines slip, which is how outsourced systems end up live without a clean record of who can do what, or what happened when.

Our design approach: build the machinery once, reuse it everywhere

The alternative is a discipline, not a trick. Over successive products we extracted the machinery that every operational system needs into a set of independent, well-bounded services — each designed to stand on its own, tested, and hardened by actually running in production. That library is Keystone, with an operations and commerce engine at its core.

When we start a new product, we do not start at zero. We assemble the foundation from Keystone and direct engineering effort at the part that is unique to the client. The reusable pieces are not generic shortcuts — they are the plumbing your system needs regardless, built to a higher standard than any single project could justify on its own, because the cost of getting them right is amortised across every product that uses them.

Today Keystone is made up of 12 reusable services and underpins 5 production products, Orchestrik among them. Because the code, testing and documentation for these services are reused rather than rebuilt, the only effort a new project spends on them is quick integration. Across our custom projects that has meant an average saving of around 18% on the total build — and that figure counts every part of the work, not just the code, but the testing and the documentation that would otherwise be redone each time.

What you would otherwise rebuild — and what it guarantees you

The clearest way to see a reusable design approach is by what it guarantees the buyer. We keep the building blocks deliberately high-level here — what matters to you is the column on the right: capabilities that come built in, rather than features bolted on near a deadline.

Built in from day one	What it means for you
Approvals	Nothing sensitive — a refund, a price change, a new supplier — happens without the right person signing off. Two sets of eyes before money moves.
Activity logging	Every action carries a name and a timestamp. When you ask "who did this, and when?", there is always an answer.
Access control	People can only touch what their role allows, and access stays reviewable. No quiet over-permissioning.
Safe retries	Press pay twice and you are charged once. Repeated or duplicated requests never act twice.
Balanced ledgers	Money and stock always reconcile by design, not by month-end firefighting.
Configurable rules	Things like cancellation, refund or reorder terms are settings, not code. Change the rule without a rebuild.
Multi-client isolation	One platform safely serves many clients, branches or regions, each kept correctly separate.
Point-in-time history	The system remembers what was true on any past date — clean audits and accurate dispute resolution.

Reuse versus rebuilding from scratch

The difference is easiest to see side by side. Same scope, two starting points:

	Rebuild from scratch	Assemble from a reusable pack
Speed	Months spent rebuilding foundations before the real product begins	Foundations integrated quickly; effort goes to what is unique
Cost	You pay for the same plumbing on every project	Built once, reused — around 18% off the total build
Quality	First-time code carries first-time bugs	Proven components carry their fixes into every build
Controls	Audit trails and approvals bolted on near the deadline	Controls present from day one

What does mature software design look like to a non-technical buyer?

Vendors love the word "robust." It means nothing on its own. Mature design is concrete, and the best examples translate cleanly for anyone, technical or not. Four from the pack:

Click pay twice, charged once. A mature system assumes networks fail and people double-click. It recognises a repeated request and ignores it rather than acting on it twice. Immature systems learn this the hard way, through a customer who was charged three times.

Two sets of eyes before money moves. Sensitive actions pass through a sign-off step — one person initiates, another authorises. It is the software equivalent of requiring two signatures on a large cheque, and it is built into the foundation rather than remembered after the first costly mistake.

The books always balance. Money and inventory are tracked the same way accountants have balanced books for centuries — every movement has a matching record, so balances reconcile by design instead of needing to be chased.

Change the rule, not the software. Business rules — refund windows, cancellation terms, reorder thresholds — live as configurable settings. When the business changes its mind, you change a setting, not a codebase. That is the difference between a system that bends and one that has to be rebuilt.

This is the same engineering discipline we describe in our approach to designing complex software, and it sits underneath the capabilities we deliver across data, automation and security.

How Keystone powers Orchestrik

The strongest proof of a reusable approach is what you can build with it. Orchestrik, our AI agent orchestration platform, runs on this exact foundation. Its tenancy, access control, approval gates, audit trails and billing all come from Keystone — which is precisely why a platform of that complexity could be stood up without first rebuilding the basics.

That matters to you as a buyer for a simple reason: the machinery we trust to run our own product is the same machinery we use to build yours. We are not asking you to be the test case for foundations we have never run ourselves.

How do reusable components control quality, cost, and audit risk?

Reuse is not only about speed. Because the same hardened components sit under every build, three things that are usually expensive afterthoughts become defaults.

Quality control. A bug fixed once in a shared component is fixed for every product that uses it, so quality compounds across the portfolio instead of resetting to zero on each project. The pack has been hardened by more than 7,000 test cases run across the combined microservices — a body of testing every new product inherits on day one rather than writing from scratch. This tracks with the wider evidence: studies of industrial software find that reused, already-tested components carry a measurably lower defect density than freshly written code (Mohagheghi & Conradi, 2007), while defects not caught until late in a project are the most expensive to fix (NIST, 2002).

Cost control. You stop paying to rebuild foundations, and you stop paying for the long tail of first-time bugs that come with new code. Budget moves from plumbing to the product features that actually differentiate you. For a fuller picture of how this changes an engagement, see our take on what mature technology partners do differently.

Auditing and logging. Because audit logs, access control and approvals are built into the foundation, the answer to "who did this, when, and who approved it?" already exists. There is no compliance scramble before a launch, no reconstruction of events after an incident — the record was being kept the whole time. The same built-in approvals and logging power the kind of governed operations console we delivered when we optimized and secured a global market intelligence website, where complex or time-consuming changes run through an approval workflow rather than ad hoc against production.

If you are weighing how to build your next platform — and whether your current partner reuses or rebuilds — this is how we work. We delivered our own AI platform and a multi-tenant operations engine on a reusable foundation, with controls and audit trails built in from day one. Tell us what you are planning and we will show you which parts you would never have to pay to build twice.

Frequently asked questions about reusable software components

What is a reusable microservices pack?

It is a library of independent, production-hardened services — things like approvals, audit logging, access control, payments and policy rules — that have already been designed, built, tested and run in production. Instead of writing this common machinery again for every project, a new product assembles it from the pack and focuses engineering effort on what is genuinely unique to the client. We call ours Keystone.

Does reusing components mean my software is generic and not custom?

No. The reusable pieces are the plumbing every serious system needs anyway — authentication, approvals, audit trails, billing, access control. Your custom logic, workflows and product experience are still built specifically for you. Reuse removes the undifferentiated rework, so more of your budget goes into the parts that actually make your product yours.

How does reuse reduce cost and delivery time?

Every project that starts from a blank page pays to design, build and debug the same foundational machinery again. Reusing components that are already proven in production removes that rebuild tax, shortens the path to a working system, and avoids a long tail of first-time bugs. The saving shows up as faster delivery, lower cost for the same scope, or more functionality for the same budget.

How do reusable components reduce bugs?

A component that has already run in production has had its edge cases found and fixed once. Reusing it means every new product inherits those fixes instead of rediscovering the same failures. Safeguards that stop a retried or double-clicked payment from charging twice, for example, are built into the pack rather than re-implemented, often incorrectly, on each project.

What audit and control capabilities come built in?

Default activity logging of who did what and when, access control, sign-off steps on sensitive actions, and ledgers that keep money and stock reconciled. Because these are part of the foundation rather than features bolted on later, they are present from day one and demonstrable on request — not a compliance scramble before a launch.

How does this relate to Orchestrik?

Orchestrik, our AI agent orchestration platform, is built on the same reusable pack. Its operational backbone — tenancy, access control, approvals, audit trails and billing — comes from Keystone, which is why a platform of that complexity could be stood up without rebuilding foundations. The same machinery that powers our own product is what we use to build for clients.

How do I tell whether an outsourcing partner actually reuses components or rebuilds from scratch?

Ask to see their reusable assets. A partner with a mature design approach can point to specific shared services, show you the controls that come built in — audit logs, approvals, access control — and explain how a new project inherits them. A body shop that quotes the same foundational work as net-new on every engagement is billing you to rebuild what they should already own.

Key takeaways

• Most outsourced software pays a hidden tax: the same foundational machinery — accounts, approvals, payments, logging — is rebuilt from scratch on every project.
• A reusable microservices pack removes that tax. Keystone assembles production-hardened services so engineering effort goes into what is unique to the client.
• Reuse improves quality because a bug fixed once is fixed everywhere, and proven components carry their edge-case fixes into every new product.
• Controls that are usually afterthoughts — activity logs, approvals, access control, safe retries, balancing ledgers — come built in from day one.
• The same pack powers Orchestrik, so the foundation we build clients on is the one we trust to run our own platform.
• When evaluating a partner, ask to see their reusable assets. If foundational work is quoted as net-new every time, you are paying to rebuild what they should already own.

References

• Mohagheghi, P. & Conradi, R. (2007). Quality, productivity and economic benefits of software reuse: a review of industrial studies. Empirical Software Engineering, 12(5).
• Tassey, G. (2002). The Economic Impacts of Inadequate Infrastructure for Software Testing. National Institute of Standards and Technology (NIST), Planning Report 02-3.