Development case study
KodaWaste
Building a configurable commercial SaaS platform for an industry where no two businesses operate in quite the same way.
What I built, and why it matters
I conceived, designed and developed KodaWaste, and I continue to operate and improve it through KodaSoft. It is a live commercial platform that gives waste-management businesses branded online ordering and the operational workflows behind those orders - from availability and pricing through to payments and invoicing.
It is not a tutorial project or a speculative demo. The same shared platform supports businesses of very different sizes and service mixes. Development has been driven by real commercial usage: real customers, real orders, real edge cases and real production support.
My role has been end-to-end - understanding how waste companies sell and operate; product and domain modelling; architecture and database design; customer journeys and administration tools; onboarding and configuration; deployment; and turning client requirements into reusable software.
Why a generic shop was never going to be enough
Waste businesses needed better online sales and self-service, but a generic e-commerce basket collapses the operational detail that makes those sales workable. Hiring a skip is not the same as selling aggregates, arranging ready-mixed concrete, booking grab work or managing portable toilets. Availability may depend on postcode, zone or site. Pricing may change by season, customer type or waste stream. Permits, prohibited materials and collection logistics sit inside the purchase decision - not after it.
Early conversations made one design constraint obvious: configurability could not be bolted on later. It had to be foundational, or every new client would push the product towards a permanent fork.
Designing for an Industry That Refuses to Be Standardised
From the outside, waste companies can look similar. In practice, the commercially correct workflow for one business can be wrong for another. There is no single universal “skip-hire checkout.”
Equipment hire vs product commerce
One company mainly hires skips with permit-sensitive on-road placements; another sells aggregates and garden products with delivery logic closer to product commerce than hire.
Consumer checkout vs account trade
Some businesses need a simple consumer journey. Others rely on account customers, project sites, reordering and staff-assisted fulfilment.
Standalone store vs embedded portal
One client needs a branded webstore of its own. Another needs the ordering experience to sit inside an existing website, with CMS-managed content around it.
Pricing that refuses one template
Pricing may be seasonal, trade/consumer split, zone-based, or revised in bulk through import and export rather than edited order by order.
The platform had to absorb that variation without becoming a different product for every customer.
A shared platform, not a collection of forks
I deliberately built KodaWaste as a shared, maintainable platform rather than a fixed storefront or a set of disconnected client systems.
Each client-facing system is a configured deployment of the same core - not a permanently branched codebase. Feature flags decide which commerce modules an instance runs. Organisation-scoped customers and orders keep data boundaries clear. CMS, company settings and custom CSS let branding and content differ without rewriting the application. Zones, authorities (permits), pricing and waste rules live as configurable domain data rather than hardcoded page flows.
Modular ordering journeys - skip hire, skip exchange, concrete, product sales, portable toilets, waste clearance and checkout - share foundations while remaining free to express different commercial workflows. Where a new requirement is genuinely common, the useful response is a reusable platform capability that existing tenants can ignore until they need it.
Implementation foundations
ASP.NET Core 8 MVC · MySQL + Dapper · custom migrations · Hangfire · Stripe / Opayo checkout · LESS, Bootstrap, jQuery and Knockout · MSTest characterisation around critical payment paths
Building and operating the whole product
Shipping a live SaaS product is broader than writing screens.
Alongside the customer journeys I built the administration and configuration surfaces operators actually use, payments and invoicing paths, reporting, background processing, and the migration discipline needed when a mature schema has to keep moving.
Operating the platform means onboarding and configuration, investigating production issues, protecting data boundaries between organisations, and keeping existing businesses stable while the product evolves. Design decisions are tested by support tickets, edge-case orders and careful migrations - not only by specifications.
From traditional engineering to AI-assisted development
The product and its domain model were established through years of direct human engineering and commercial experience. AI now accelerates that work - it does not replace the ownership underneath it.
Then - establishing the product
- Requirements gathered directly from waste businesses
- Architecture and code designed and written by hand
- Traditional debugging, research and production testing
- Incremental releases guided by real users and transactions
- Domain knowledge accumulated through support and operation
Now - accelerating a mature platform
- The same product ownership and engineering responsibility
- AI-assisted planning and codebase exploration
- Faster debugging, refactoring and test improvement
- Quicker evaluation of approaches and migration risk
- Greater capacity to improve mature parts of the system carefully
I now use AI tools extensively - including Cursor, ChatGPT, Claude, Gemini and, where appropriate, locally hosted models through Ollama - to explore a large mature codebase, break broad requirements into implementation plans, surface regression risks, review database changes, improve documentation and prototype carefully reviewed capabilities.
KodaWaste is not an “AI-built” product. AI did not invent the domain model or the commercial judgement underneath it. It is valuable because I can judge its suggestions against years of product, codebase and industry knowledge. That combination has increased both the pace and the ambition of improvements - without transferring responsibility away from the engineer who still ships and supports the system.
Grown under commercial pressure
Serving an increasing range of smaller independents and larger, more complex operators continually stress-tests the design. Smaller businesses need clarity and low administration. Larger ones need deeper configuration, reporting, controls and integration points. The hard part is supporting both without making the product overwhelming.
New requirements regularly expose assumptions in existing workflows. The useful response is usually not a one-off special case; it is a safe, reusable capability that existing tenants can ignore until they need it. Stability for current businesses remains a first-class constraint on every evolution.
What this work taught me
- Domain understanding matters as much as technical skill. Waste-industry commerce only becomes software once the operational differences are taken seriously.
- Configurability has to be designed deliberately. Bolting it on later is expensive and usually creates forks in disguise.
- Not every client request should become a permanent customisation. The better outcome is often a reusable platform capability.
- Mature software demands compatibility and migration thinking. A live schema has to keep moving without breaking the businesses already on it.
- Production support reveals problems specifications rarely predict. Edge-case orders and operational pressure are part of the design feedback loop.
- Simplicity for the user often hides substantial complexity behind the interface. Clean journeys are an engineering achievement, not an absence of difficulty.
- AI assistance is most valuable when paired with critical judgement. Deep product and codebase knowledge is what makes the acceleration safe.
- Long-lived products improve through continuous refinement. There is rarely a single clean build that survives years of commercial use unchanged.
What KodaWaste says about how I work
KodaWaste is the clearest example of how I work as a software developer: long-term ownership, commercial awareness, careful domain modelling, full-stack delivery and architectural judgement under real constraints.
It also shows the ability to work directly with users, accept production responsibility, and modernise a mature product with AI-assisted engineering - without abandoning the discipline that made the platform reliable in the first place.