There are two ways to build a software product.
The first: research a market, identify a gap, map personas, conduct interviews, generate a hypothesis about what people need, build it, and hope that the problem you've described matches the problem people actually have.
The second: live the problem so clearly and so personally that not building the solution eventually becomes harder than building it.
Rainbow Octopus LLC was built entirely on the second approach. Here's why that matters — and what it produces.
The problem with building software you haven't lived
Research-driven products are often technically correct. They solve the problem that was described in the research. But they frequently miss the texture of the problem — the specific, daily, human frustrations that only become visible once you're inside them.
When you've lived the problem, you know which features matter at 11pm when something goes wrong. You know what the edge case looks like when you're scared. You know what gets in the way when you're in a hurry, frustrated, or tired. You know which parts of the experience feel wrong even if they technically work.
That knowledge does not come from research. It comes from experience. And it produces fundamentally different software.
WoofWyse: built the night it was needed most
Our founder has eight dogs — Cane Corsos and Rottweilers. Managing their health records meant scattered notes across apps, WhatsApp messages sent to himself, and handwritten medication schedules on whiteboards that kept getting erased.
When one of them needed emergency veterinary care, he arrived at the clinic without the information the vet needed. Vaccine dates. Medication doses. Known allergies. Things he had written down somewhere — just not somewhere accessible at that moment.
He searched afterward for a tool built to prevent exactly that situation. He found apps for casual pet owners, not for people who treat animal care with genuine seriousness. He built WoofWyse for himself first. Then for everyone like him.
InvoiceBaby: built after the relationship it should have saved
Our co-founder worked across multiple markets as a professional. Getting paid meant navigating tools built for US businesses, in US dollars, with US tax logic — tools that required his international clients to create accounts and navigate registration flows before they could simply pay an invoice.
He lost a client over a login screen. A good client. A finished project. The relationship ended not because of the work, but because the billing process had friction that should never have existed.
InvoiceBaby started as a weekend project to fix five things that invoice tools got wrong for international freelancers. It became a real product when the first invoice sent through it was paid within the hour.
What this means for how we build
We are a small company. We do not have large research teams or extensive focus groups. What we have is a direct, personal understanding of the problems our products solve — because we have needed those solutions ourselves.
When a WoofWyse user reports a bug in the medication schedule feature, we feel its urgency personally. When an InvoiceBaby user asks for a cleaner payment link format, we understand the exact context — because we've been on both sides of a confusing invoice.
This is the product philosophy of Rainbow Octopus LLC. Our founders have lived and worked across Africa, Europe, and North America. We build software for the problems we have lived, because we know first-hand that no one else will solve them quite right.