Platform instead of boilerplate: which parts of a client project should be reusable

Almost every software company has an internal framework – and almost every one has buried one. The difference between a viable base and expensive ballast rarely lies in the technology. It lies in where you cut: what goes in, what stays out, and who decides that?

1. The same foundation every time

The same building blocks appear in every business software project: user management, roles and permissions, tenant or organisation context, master data, data access, history, file storage, reporting foundations, auditability. No client is interested in them in domain terms – yet they pay for them, in every project anew.

2. The criterion for cutting

Instead of long debates, one question helps:

“Similar” is the trap. Two projects both need approval logic, but with different states and rules. Pull those together and you build a configurable monster that serves both projects worse than two separate implementations would.

3. What belongs in the base

• Identity, roles and permissions. Always the same in domain terms, security-critical, expensive to build yourself.
• Tenant and organisation context. Extremely expensive to retrofit, so in the base from the start.
• Data access and modelling. Consistent patterns for entities, relations and validation rules.
• History and traceability. Almost always required, almost always underestimated – see audit trails.
• Cross-cutting concerns: error handling, logging, configuration, internationalisation.
• A delivery skeleton: build, containers, pipeline templates.

4. What stays out

• Domain logic. Always. Even when two clients need “almost the same thing”.
• Interface specifics beyond a shared design framework.
• Integrations with client systems – each is different, even when the target system has the same name.
• Anything with exactly one consumer. A building block for one project is not a building block but code in the wrong place.

5. Copy-paste boilerplate and its cost

The most widespread form of reuse is copying a project skeleton. On day one it is the fastest option and over the years the most expensive:

• A security issue has to be fixed individually in eight projects.
• Improvements do not flow back – every project drifts further apart.
• Moving developers between projects gets more expensive, because everything feels “almost the same”.
• Evidence of consistent quality standards cannot be produced.

The distinction is therefore less technical than organisational: boilerplate is copied, a platform is referenced and versioned.

6. Versioning and migration

A base without version discipline becomes a millstone. What works:

• Semantic versioning with a clear statement of what counts as a breaking change.
• Several supported versions at once – projects cannot all migrate simultaneously.
• Migration guides per breaking change, ideally with automated rewrites.
• Plan a maintenance window per project; without reserved time the migration never happens.
• Organise the flow back: whatever emerges in a project and is generally useful moves back into the base – with review.

7. Multi-tenancy as a special case

Multi-tenancy is the point at which it is decided early whether a base will carry weight long term. Retrofitting it means touching every query, every permission check and every data migration. It therefore belongs in the base even when the first project has only one tenant – provided the model is consistent from the start and enforced centrally, not per query.

8. Why internal frameworks fail

1. No owner. A base without a responsible team becomes a side project and goes stale.
2. Generalised too early. Abstracting after the first project almost always picks the wrong axis.
3. Too much inside. Once domain logic moves in, every change becomes political.
4. No migration paths. Projects stay on old versions and the base effectively decays into forks.
5. No documentation. Whatever is not described gets worked around – by people and by agents alike.

9. Build it or adopt one

Building your own base pays off when enough projects benefit, a team can own it permanently and the requirements are so specific that standard solutions do not fit. It does not pay off when it is meant to run alongside day-to-day work – that produces a base that is never finished and never current.

This is exactly where CodamAI comes in: as an existing, maintained foundation for data, identities, permissions and delivery, on which the domain logic is built individually. Details on the features page; the commercial side in the deep dive AI for software companies.

Checklist: cutting the base correctly

Conclusion

Reuse rarely fails on technology and almost always on where you cut and who owns it. Limit the base to what is genuinely identical, version it instead of copying it and give it a responsible team, and you get exactly the effect AI tools alone do not deliver: less work arising in the first place.

That is unspectacular and feels slow – but it is the only lever that compounds across projects instead of being pulled anew every time.