John Nowak is CTO and Co-founder of Grappler. We sat down with him to talk about the development philosophy that has shaped the Grappler platform over eleven years, and why he still builds software with that same intent since day one.
You use the phrase "holding intention lightly”. It sounds almost philosophical. How does it relate to software development?
It's about accepting that the truth is true in that moment but not getting stuck thinking that's how it has to always operate. Insurance is a complex, document-heavy world. What a customer tells us upfront about how their process works is rarely the full picture. LPANs are a good example.
A London Premium Advice Note is used for central accounting in the Lloyd's insurance market. It’s basically a document brokers use to submit premium details for processing. On paper it sounds straightforward but in practice you have rules around multiple LPANs, different premium types, geographic territories, currencies and global contracts that make it really complicated. What customers told us upfront about how it worked wasn't what was needed in practice. If we'd locked in our assumptions early, we'd have built the wrong thing. Building open-ended meant we could keep revisiting it as the different challenges emerged.
Was iterative development a deliberate choice, or did circumstance lead you down this path?
Completely deliberate. Iterative development has always been my preferred approach, it's how I'm wired. And I'm a SaaS purist, so the two go hand in hand for me. Otherwise you get bogged down in monster requirement documents and then I have to sit down and read them, decipher them and build in the hope that the requirement was correctly specified in the first place.
How did it play out in the early days of Grappler?
We started with our first customer by solving one small problem - a straightforward premium reconciliation. Then we added on, and added on, and added on. A new customer would come on board with new requirements and the cycle would start again. It became our default process, not by design, just by doing it and realising it worked for us.
Eleven years in, with a lot of code, and an end-to-end insurance accounting platform it's still how we operate. The temptation is always to tackle something in a big-bang approach. You know, draft a big development plan, have a big planning kick-off. But that doesn't suit how we operate. We nibble at a problem rather than bite it - get the smallest functional piece out into the wild, then iterate and improve. Again and again and again - customers benefit from the limited functionality available early, and we benefit from customer feedback on what might be wrong or missing.
What does that look like at the code level?
We do so much by configuration. Our code is deliberately open, not a hard path. We maintain a single codebase for all customers, everyone is always on the latest version. Differences between customers are managed through configuration and feature flags at a customer level.
It means we can roll out new functionality to everyone continuously without disrupting live environments. No one gets left on an old version. That's the true SaaS model and it's only possible because we never let ourselves get locked into bespoke development based on individual change requests.
Are there any downsides to that model?
Continuous releases and feature flags work well technically but they create a communication challenge for our support and comms teams as customers don't always know new features are available to them. That's on us to fix, not the architecture. We're addressing it through quarterly product communications so customers actually get the benefit of what we're shipping.
After eleven years, what's your key takeaway?
Eleven years of solving, adding, iterating means the platform today carries a depth of knowledge that only comes with time. We're still learning from our customers, and everything we learn goes back into the platform.
The best software is never finished. Stay curious, stay agile, keep shipping.