New product engineering, for products that have to survive their own growth
We build software to specification: new products, headless content architecture, and greenfield builds inside enterprises, for FMCG groups, retailers and organisations handling payment or other regulated data. Recent work includes a multilingual public programme platform for Energy Upgrade California, a high-traffic consumer platform for Royal Canin, and a content platform serving several dozen countries for Forbes 500 company.
Trusted by global and local brands since 2008
Four kinds of work, one engineering standard
Most projects fall into one of these categories. They share a common foundation, so we keep them together on one page instead of splitting them up.
Tailor made software
Software built to a specification rather than configured from a package. Product platforms, customer facing systems and internal tools, including systems that carry payment or personal data. We take the architecture decisions with you and stay accountable for them afterwards.
Headless CMS architecture
Content managed and delivered through an API, so editorial work and product releases can move at different speeds. This is the usual shape for multi market, multi brand estates where the same product data feeds a website, an app and retail partners. It is also where Flotiq, our own headless CMS, normally enters.
Scale-up engineering
For products that worked at their first size and then grew. We measure where the system actually slows down, then change those parts while the product stays live. Usually the cause is traffic arriving in peaks rather than evenly, or a data model that assumed a single market.
Enterprise delivery
New builds inside organisations that already run substantial systems. The engineering standard is the same. What changes is the constraints: security review, procurement, audit sign off, and integration with platforms nobody fully documented, on the timeline those actually take.
Why the first version decides what the third version costs
The first version is often built quickly to reach users, test your idea, and secure more funding or budget. Most technical choices made at this stage make sense for the moment.
Problems tend to appear later and rarely as one big failure. For example, a data model that worked for one market may not fit another. Authentication designed for one user type may not handle roles. A release process that suited a small team can slow a larger one. These decisions made sense at the time but were never reviewed. As a result, issues often show up as slowdowns instead of outages.
The real difference is not about speed or caution. It is about which choices are easy to change later and which are hard to reverse. Only a few decisions can be safely delayed. Even fewer, if made early, become costly to fix.
Building fast and building something that survives scale are not opposites. They are the same work, done in a particular order.
Signs a build is heading for an early rebuild
These usually appear before anyone is willing to say the system itself is the problem.
VELOCITY
Features take longer than they did a year ago and nobody can say exactly why. Estimates stretch, and the same size of change costs more each quarter.
DATA
Every new requirement fights the data model. New fields arrive as new tables and workarounds, and product or customer data has no single source.
RELEASE
Deployments have become events. Releases wait on a window rather than on a decision, and someone has to be free afterwards in case.
KNOWLEDGE
One or two people understand how the system actually works. Everyone else builds around them, and onboarding takes months rather than weeks.
COST
Infrastructure spend rises faster than usage. Nobody can attribute it to a market, a brand or a feature.
TRUST
There is an area of the system nobody volunteers to touch. Bugs get reported and no one can evidence what changed, or when.
Get a free consultation with our experts and CTO
Let's talk about current challenges and see where we can help.
How a new product gets built, from first shape to operating system
Four stages, in the order they actually happen. Each one ends somewhere the product can sit for a while without the next stage having been started. The stages are set up so the most expensive decisions come first, while other choices can wait.
Shaped
The problem, the constraints and the first version's boundary, agreed before anything is built. This is where security review, data residency and integration with existing systems get discovered, rather than three months later when the architecture is already fixed. Leaves behind: a scope someone can say no to, and a written record of the decisions that set it.
Shipped
The first version goes live for real users, built on foundations you can add to. It ships into an environment that meets your access and change rules from the first deployment, not into a sandbox that is later made compliant. Leaves behind: a product in production, deployable on demand rather than on a release date.
Scaled
Someone takes responsibility for uptime, cost and security once the build is over. Shared on call, cost attributed per team or market, and a named owner rather than whoever is closest to the code. leaves behind: a product with a named owner, not a team hoping it stays quiet.
Operated
Someone takes responsibility for uptime, costs, and security over time. On-call duties are shared, service level objectives are tied to real user impact, and the system is documented so your internal team can take over as it grows. leaves behind: a product that runs, and a team able to run it.
The same four stages, three different sets of constraints
The engineering stays the same, no matter your company size. What changes is everything around it, and that usually sets the timeline.
| Startup | Scale-up | Enterprise | |
|---|---|---|---|
| Hardest part | Deciding what not to build yet | Changing structure without stopping | Integrating with systems nobody fully documented: core banking, ERP, market specific product data |
| Constraint that sets the pace | Runway | Traffic already arriving | Security review, procurement and audit sign off |
| Who decides | One or two founders | A product lead and a stretched engineering team | Several stakeholders with different definitions of done |
| Where a build usually fails | Building for a scale that never arrives | Deferring structural work until only a rewrite is left | Requirements settled after the architecture is fixed |
| Typical entry point | Discovery or MVP build | Scale-up review | Discovery, then a contained first delivery |
| What Flotiq tends to shorten | Time to a first version | Multi-market and multi-brand content | On-premise content delivery under existing policy |
Should content be headless at all
Choosing a headless setup is an architectural decision before it is a product decision. Content turns into an API, delivery becomes a separate task, and editors no longer have to wait for releases. But it also adds complexity, which is not always worth it.
Headless earns its keep when
A coupled CMS is the better choice when
More than one channel consumes the same content.
One site is served by one team and content changes rarely.
Multiple markets, languages or brands are likely, as they are across most FMCG portfolios.
Nobody is going to maintain a second deployable.
Non-technical people need to change things without a release.
The product is transactional, with little editorial content.
The front end is expected to be replaced before the content is.
An existing platform is already working adequately.
The content layer has to run in a regulated or on-premise environment.
The cost of a rebuild outweighs the flexibility gained.
Where Flotiq fits in the stack
Flotiq is our own headless CMS and the platform we use most often. That is why we are clear about its limits.
Otherwise built from scratch
What we need
Content modeling and an editorial interface
Structured content types, editor UI, versioning
A content API, caching and delivery
API-first delivery with predictable performance under load
Multi language and multi market transformation, the standard shape of an FMCG brand estate.
Localization and market variants as configuration
Media handling and transformation
Asset management and on-the-fly image processing
Deployment and hosting decisions for the content layer
Managed or on-premise, including regulated environments
Where Flotiq is the wrong tool
What to do instead
The core value is a proprietary algorithm or data pipeline
Build the core properly. A content platform belongs at the edges if anywhere.
Requirements point to a relational core with complex integrity rules
A relational database and a bespoke admin, not a content platform
An existing content platform is already working adequately
Leave it. Migration cost rarely returns on a system no one complains about.
The organization has standardized elsewhere for good reasons
Work with what exists rather than adding a second content system
What clients said afterwards
"Thanks to the dedication and experience of CODEWAVE team our cooperation has been successful for over 10 years. Solutions they provide are critical to the functioning of Tesco's website. I would recommend CODEWAVE to anyone looking for comprehensive software development service for their web applications."
"Since the implementation, we have seen a significant improvement in performance metrics, incl. 86% reduction in TTFB. Thanks to CODEWAVE we can enjoy our service accessed by a few thousands of employees without the risk of the system crashing."
"The team faced challenges due to a lack of team members familiar with WordPress, which made website management difficult. Thanks to the migration to a headless CMS platform, supported by Flotiq, everything changed for the better. The cooperation was seamless, and the page was migrated without any issues."
Talk through a possible engagement.
We offer a technical conversation about what you are building, what might be stuck, or what is not working, and we will give you an honest opinion about whether we are the right team for the job.
What a scale-up engagement is, and what it is not
This is the most common starting point for a product built by someone else. Growth is already underway, so stopping to rebuild is not an option.
What it does
What it is not
Measures where the system actually breaks, under real load rather than in theory.
A rewrite. It happens when this work is deferred too long.
Changes structure incrementally, with the product live and shipping throughout.
A rescue that requires a feature freeze.
Establishes a performance and cost baseline, so growth stops being a surprise.
A judgment on the engineers who built the first version under different constraints.
Makes the system legible to a team that is about to double.
A parallel team working around the existing one.
Leaves the internal team able to run what was changed.
A permanent dependency. Handover is part of the engagement, not a later phase.
Where an engagement can begin, from a product review to full ownership
We offer a range of engagement options, not just a fixed menu. New projects often start with Discovery or an MVP build. Products already in the market usually begin with a Scale-up review.
Measured in production, across banking, FMCG and retail builds
- 0k+
- stores served through a single content platform, across several dozen countries
- 0%
- responsiveness increase after a Flotiq migration
- 0s
- An e-prescribing workflow reduced from fourteen steps to around thirty seconds
Products built for FMCG, retail and banking clients since 2008
A product that has already failed the growth test is a different problem. That work sits on:
Have questions about Software Engineering?
Why do healthcare providers choose custom software instead of off-the-shelf solutions?
Discuss a new product build
Let’s have a technical conversation about what you are building, what stage you are at, and what the first three months should really include.
