A real case: the merchant shapes its own ERP
A Shopware merchant is developing a new web-based ERP for its niche with Codex. The new ERP is designed to replace a system more than twenty years old. The idea comes from inside the business: the merchant knows the workflows and builds the application around that experience. [S144]
The merchant’s role changes. Working with a coding agent, it can turn a workflow into software and try it before commissioning a complete external design. The application reveals whether a rule is clear and works in daily use.
Because an ERP connects purchasing, products, stock movements and accounting, the merchant’s niche knowledge is particularly valuable. It knows which exceptions recur and which supposed special cases are normal business. That knowledge can now become the software’s direct starting point.
Replacing the system also involves the business’s history. Germany’s GoBD rules require an equivalent transfer of tax-relevant data, including necessary links; procedural documentation also belongs in the project. Migration and tax coordination therefore remain distinct tasks. [S148, S149]
The case points to a different division of work. Merchants shape solutions and identify where they need help. Developers, agencies and specialists bring the experience needed for dependable operation. Businesses gain independence as the distance between their knowledge and a usable application shrinks.
A real case: a blocked migration finds a way forward
A new Shopware customer had spent years without finding an economically viable way to replace its shop system. Its business model required functions a standard shop did not provide. The Community Edition offered a foundation on which the merchant could use Claude to implement those requirements in its own extensions. [S144]
The business idea already existed; the merchant needed software to match. It can now describe a requirement, try a design and develop it around its workflows. It can shape the migration directly.
Extensions build on the existing shop. Product management and orders need not be reinvented for every distinctive requirement. The merchant can concentrate on the rules that define its business. Open code and a coding agent provide a direct route into the system.
A working application changes the agency relationship because merchants can use it to explain their requirements. Advice, architecture, testing and maintenance start from a concrete solution. This brings business knowledge and technical experience together earlier in the project.
Both anonymized cases come from merchants I know and show what merchants can undertake with coding agents: an operational core system or the requirements of a complex shop. What fascinates me is business experience becoming direct working material for software. More companies can shape their own ways of working rather than adapt them to what they could previously afford.
The brief becomes a prototype
At Werkpunkt, the idea starts with a spreadsheet. A maintenance buyer pastes a list of spare parts from an internal system; sales staff assemble article numbers, variants and customer prices. The desired quick-order flow is clear: upload the list, review recognised items, resolve ambiguity and prepare an offer.
Let a coding agent build the first version on a copy of the shop, using existing product and pricing functions. The initial screen already reveals the real work: an abbreviated description matches two revisions of the same machine. The customer must answer that question before the list becomes an offer. An attractive upload button would merely have moved the ambiguity along faster.
With the brief already expressed as a prototype, the agency can examine the business journey and agree with the merchant how to turn it into a maintained extension. For me, this is a major opportunity in agent-assisted development: ideas become tangible before a large project budget is committed.
Open code as working material
Coding agents such as Codex and Claude Code can read a codebase, trace dependencies and propose changes. An open core lets them inspect the commerce logic. People can review the same path. Closed platforms also enable customization through APIs; the available depth and control differ.
A customer price may depend on a contract rule added by another extension. An agent with access to the code can follow that relationship and find the intended extension point. Documentation and test data then help verify the change through an order.
What changes for agencies
Faster implementation increases the value of deciding which distinctive requirement improves the business. An agency helps make that choice, designs the supporting architecture and agrees how it will operate after the next update. Its responsibility therefore begins well before final acceptance.
| Task | With coding agents | Agency contribution |
|---|---|---|
| Clarify the idea | Merchant and agent build an initial version | Sharpen business logic and UX |
| Implementation | Many changes can be generated quickly | Define extension points and architecture |
| Quality | More variants become possible | Check security, performance and real edge cases |
| Operation | More custom extensions remain in circulation | Maintain updates, monitoring and recovery |
| Commercial model | Implementation time becomes less scarce | Offer prototype sprints, coaching and operations packages |
An operations package names the extensions covered, response times and included updates. For outcome-based fees, merchant and agency agree on the benefit measured and how external influences are treated. A new pricing idea becomes an offer both sides can work with.
Nordstern (fictional): advice that used to cost too much
Nordstern builds an outdoor trip planner for customers who plan outside store hours, extending advice that was previously economical for only a few orders. Destination, season, existing equipment and preferences lead to a suitable selection.
For one product group, the prototype uses verified attributes, stock and storefront prices. Missing facts prompt questions; experienced advisers try familiar trips and correct mistaken conclusions. Before launch, advice, basket and service must retrieve the same selection. Nordstern can then add more practical knowledge, creating distinctive advice whose depth would previously have been too expensive to offer.
Werkpunkt (fictional): a parts list becomes a quick-order tool
Werkpunkt turns the earlier design into an extension where customers paste spare-parts lists. The agent matches articles while the shop supplies customer prices and delivery information. Unclear machine revisions go to a specialist before an offer is prepared.
A coding agent helps build the screen and connections; merchant and agency check familiar lists and common errors. Read-only customers can review results without ordering. This niche capability can later become a managed procurement service, built around known machines, approved parts and the customer’s purchasing rules.
Lichtfeld (fictional): a collection experience with a dependable basket
Lichtfeld uses a coding agent to develop a collection experience from its images, product information and design rules. The team directs the atmosphere and tries alternatives in the working design.
Every displayed product stays linked to an actual article. Colour and finish choices retrieve valid variants, prices and availability; the basket uses that selection. Starting with one collection, Lichtfeld learns which presentation helps customers choose and how to maintain it before extending its style to further rooms and ranges.
Three shortcuts that become expensive
One is changing the core despite an available extension point. The next update brings together two changes designed without knowledge of each other. Another is uncontrolled data access: a preview rarely needs the entire customer database. The third is a private fork without a maintenance plan. The first version arrives quickly; nobody feels responsible for later updates.
Use a simple workflow: state the task and limits, develop on a copy, review the change, accept it against a normal case and a counterexample, then release a limited scope. Record the rollback path and operational responsibility. This can start small.
A calculation template for your own projects
What platforms need to provide
Platforms now serve two kinds of developer: people and their agents. Stable extension points, clear errors and traceable business operations help both. AGENTS.md files or skills explain conventions and necessary checks. Test data and private previews shorten the path to a useful result.
The Lab’s Agent in a Box provides this project workspace; Chapter 13 explains its security boundary. [S109]
Which experiments deserve the next investment? The next chapter shows how we approach that question in the Lab.