Frequently asked questions
Straight answers about what TrueForge does, how engagements run, and what modernisation actually costs. Written to be quoted, not to hedge.
The questions people ask us most.
Grouped so you can jump straight to what you need. Every answer stands on its own.
What TrueForge is, and who we serve.
The short version of who we are, where we work, and how we stay independent.
What does TrueForge do?
TrueForge is an independent boutique technology consultancy that helps organisations modernise ageing systems and build new software that lasts. Our work spans legacy modernisation, systems integration, composable architecture, custom software engineering, architecture and technical leadership, managed services, security and compliance, and AI and data engineering. We are vendor-neutral and engineering-first, so our recommendations are driven by what fits your business rather than by a product we are trying to sell.
Who is TrueForge for?
We work with both enterprise and regulated organisations and small and mid-size businesses. Larger clients typically engage us for complex modernisation, integration and architecture programmes, while SMBs come to us for pragmatic custom software and ongoing engineering support. The common thread is teams that depend on software to run their business and want an independent partner who builds for the long term.
Which regions does TrueForge serve?
TrueForge is registered in Dubai Internet City with an office in Dubai Media City, and we serve clients across the UAE and the wider MENA region, drawing on a European engineering heritage. Working across these markets means we are used to varied regulatory environments, time zones and delivery models. Engagements can be delivered on-site, remotely or as a blend, depending on the work and the client.
Which industries does TrueForge work with?
Our four core sectors are financial services and insurance, telecommunications, healthcare, and manufacturing and logistics. Beyond those we work industry-agnostically with organisations that carry significant legacy systems, integration complexity or regulatory obligations, including the public sector, retail and e-commerce and growing SMBs. Because our approach is vendor-neutral, the same engineering principles apply across domains.
Is TrueForge ISO 9001 certified?
Yes. TrueForge is certified to ISO 9001:2015 for its own quality management system. We pursued it voluntarily (no client, tender or regulator required it) because we wanted the way we actually work to be reviewed by someone independent of the company. For clients that means our quality management is a documented, audited working system rather than an informal habit: how we review requirements, handle defects and record decisions is written down the way it happens, and checked from outside.
Do you work with small and mid-size businesses?
Yes. TrueForge deliberately serves SMBs alongside larger enterprises, and being a boutique consultancy means smaller clients get senior engineering attention rather than being handed to junior teams. For an SMB this usually means custom software, integration between the tools you already run, and dependable ongoing support sized to your budget. The same engineering-first, lock-in-aware principles apply at any scale.
Why does vendor-neutrality matter when choosing a consultancy?
Because a consultancy tied to specific products has an incentive to recommend those products, even when they are not the best fit. TrueForge is independent and does not resell or favour any particular platform, so our advice is based on your requirements, total cost and the risk of lock-in. That independence is central to how we keep clients in control of their own technology choices over time.
How an engagement actually works.
The four-stage method, realistic timelines, and what "done" really means before you commit.
What is TrueForge's four-stage delivery method?
Every engagement follows four stages: Assessment, Design, Delivery and Support. Assessment establishes the current state, risks and goals; Design produces a target architecture and a realistic, sequenced plan; Delivery implements the work in incremental, verifiable steps; and Support keeps the result running and evolving after go-live. The structure keeps decisions transparent and lets clients see value at each stage rather than waiting for a single big release.
How long does legacy modernisation take?
There is no fixed answer, because timelines depend on the size of the system, its technical debt, integration complexity and how much can be delivered incrementally. Our Assessment stage exists precisely to give you a realistic, evidence-based estimate before any commitment, rather than a generic figure. In practice we structure programmes so that useful improvements ship along the way instead of value arriving only at the very end.
How do we get started with TrueForge?
Most engagements begin with a conversation about your goals and constraints, followed by our Assessment stage, which produces a clear picture of the current state and a recommended way forward before any large commitment. From there we agree scope, sequence and a delivery model that suits you. You can reach out through the contact form on this site to arrange that first discussion.
Should we rewrite our legacy system or modernise it incrementally?
In most cases incremental modernisation is the safer choice, because a working system encodes years of business behaviour that a full rewrite deletes on day one. A rewrite genuinely earns its cost in three situations: when the platform is effectively dead (an unsupported runtime, no security patches, nobody left who can build it); when the domain has changed so much that the old system models a business you no longer run, so you are replacing logic rather than porting it; or when you can carve a clean seam: rewrite one bounded piece behind a stable interface, run it alongside the old system, and cut over once it proves itself. If the real reason is simply that the code is hard to read, that is a refactor, not a rewrite. Our Assessment stage exists to work out which case you are actually in before any commitment is made.
What does 'done' mean on a modernisation project?
Done does not mean the new system is live. A launch where the demo works and everyone is happy is not the finish line if the old system is still running quietly in the corner, feeding reports someone forgot they depended on. We treat a modernisation as done only when the legacy system is actually switched off and decommissioned: the old database taken read-only, then archived, then dark (in regulated environments, into a compliant retention archive rather than a loose export); every report and integration that ran on it reassigned to a named owner who has signed off on the new source; and someone having run the old workflow end to end and hit a hard stop. Until the old system is off with its owners signed off, the project is not finished; it is dual-running, and paying for two systems at once.
How we build, and what it costs.
Rewrites versus incremental change, composable architecture, lock-in, security, and why modernisation costs more than a lift-and-shift.
Do you do full rewrites or incremental modernisation?
We favour incremental modernisation over risky big-bang rewrites wherever it is viable, because replacing a working system all at once is one of the most common ways modernisation programmes fail. Techniques such as the strangler fig pattern let us replace a legacy system piece by piece while it stays in production. A full rewrite is only recommended when the existing system genuinely cannot be evolved, and even then we sequence the work to limit risk.
What is composable architecture?
Composable architecture is an approach to building systems from independent, interchangeable components connected through well-defined APIs, so each capability can be developed, replaced or scaled on its own. It is closely associated with MACH principles (microservices, API-first, cloud-native and headless). The benefit is flexibility and reduced lock-in: you can change one part of the system without rebuilding the whole thing.
Do you offer ongoing managed services?
Yes. Beyond project delivery, TrueForge provides managed services to operate, maintain and continuously improve the systems we build or take over. This covers monitoring, support, security updates and incremental enhancements so software keeps performing as the business changes. The Support stage of our method is designed to flow naturally into a longer-term managed-services relationship when that is what the client needs.
How do you handle security and compliance?
We build security into architecture and delivery from the start and help clients meet the standards that apply to them, such as ISO 27001, the UAE Personal Data Protection Law (PDPL) and the EU General Data Protection Regulation (GDPR). Our role is engineering: secure design, data-protection-aware integration, access controls, observability and documentation that support a client's own audits and certifications. Formal certification against those standards always rests with you and your auditors, and we make the underlying systems ready for it. TrueForge itself is ISO 9001:2015 certified for its own quality management, which we adopted voluntarily rather than because any client, tender or regulator required it.
What is vendor lock-in and how does TrueForge reduce it?
Vendor lock-in is the situation where switching away from a supplier, platform or technology becomes prohibitively costly or difficult, which weakens your negotiating position and limits future choices. We reduce it by favouring open standards, clear API boundaries, portable data and composable designs that keep components replaceable. The goal is software you genuinely own and can change, rather than software that quietly traps you.
Why does modernisation cost more than a straight migration?
Because you are buying two different things. A migration changes where your systems run: it moves the boxes onto new infrastructure, largely as they are. Modernisation changes what your business can change next: the boundaries, the data model and the rules themselves. That typically costs two to three times a like-for-like migration, because you are re-deriving decisions the old system froze into place. The people who made those decisions have often moved on, the documentation was never written, and the original intent now survives only as behaviour buried in procedural code. You are not simply porting logic; you are reconstructing why it worked that way in the first place. A migration that lifts an old system onto modern hosting can leave the thing that made change slow completely untouched, which is why the cheaper option sometimes solves nothing.
Recognise your own system in any of this?