1 May 2026
Most software development studios only build for clients. We do that too, but alongside client work, we've shipped 8 of our own products: ClassyDoc, Moonlight Monitor, Shrnk.ly, Contactable, Docutrix, IpponBoard, AmpFleet, and Street Museum.
Some of these make money. Some were learning exercises. All of them taught us things we couldn't have learned any other way. Here's what we took away from the experience.
This sounds obvious, but it's surprisingly hard to do in practice. When you're building your own product, there's no client to tell you "that's enough for now." You keep adding features because you can.
With Shrnk.ly, we set a hard deadline of one month. URL shortening, click analytics, QR codes. That's it. No user management system, no team features, no integrations. One month, then ship it.
That constraint forced us to make better decisions faster. And the product was useful from day one.
We built ClassyDoc as a general document classification tool. Torqn, our first real user, used it for spam detection in their application. That wasn't on our roadmap. But their use case was valid, and their feedback shaped the product into something much more practical than what we'd originally designed.
The lesson: get your product in front of real users as soon as possible. They'll show you what it's actually for.
We built IpponBoard for iOS, macOS, and Windows from a shared codebase. The upfront investment in cross-platform architecture paid off every time we shipped an update. One codebase, three platforms, one set of bugs to fix.
For mobile apps, we've seen the same pattern with Flutter and React Native. The cost savings are real, and the quality gap with native apps has closed significantly.
We're developers. Building the product is the fun part. Getting people to find it and use it is a completely different skill set.
Our most successful products had built-in distribution. Contactable spread through WordPress sites. ClassyDoc got traction through a direct partnership with Torqn. The products we just launched and hoped people would find? Those were slower to grow.
If you're building a product, think about distribution before you write a line of code. How will people discover this?
Every product you ship is a product you maintain. Dependencies need updating. APIs change. Users find bugs. Operating systems release new versions.
We learned to factor maintenance into every product decision. If a feature adds ongoing maintenance burden, it needs to justify itself. This thinking has made us better at advising clients on what to build and what to skip.
This is the most valuable takeaway. When a client asks us to build an MVP, we're not guessing about timelines or technical trade-offs. We've done it, multiple times, with our own money on the line.
We understand the pressure of shipping fast because we've felt it ourselves. We know which shortcuts are acceptable and which ones create problems later. And we can give honest advice about whether an idea is ready for development or needs more validation first.
If you've got an idea you want to bring to life, get in touch. We'll give you the same honest assessment we give our own projects.
We specialise in turning ideas into working products fast. Tell us what you're building and we'll show you how we'd get it done.
Australian dev team. 10+ products shipped. Free initial consultation.
