How Our Experience Shapes What We Build

None of the products we've built at ShellRick Tech started as a market gap we spotted from the outside. Every one of them started as a problem one of us had actually sat inside of, usually at a day job, usually for long enough to know exactly where the friction was and why the obvious fixes didn't quite work.

That's not a coincidence, and it's not just a nice story to tell. It's the actual filter we use for deciding what to build next. If neither of us has direct, hands-on experience with the problem, we're far more cautious about building a product around it, because secondhand knowledge of a problem produces secondhand solutions, and those tend to miss the details that make a tool genuinely useful instead of just plausible.

It would be easier, in some ways, to pick products by looking at what's trending or what a keyword tool says people are searching for. We don't build that way, mostly because we've watched what happens when a product is built by someone who's never done the underlying job. The feature set looks reasonable on a slide. It falls apart the first time a real user tries to use it the way the job actually works, not the way it looks from a spec sheet.

Sorted Nexus is the clearest example. We built it because ShellRick Tech itself needed a way to handle quotes, invoices, and cash flow tracking without stitching together spreadsheets and separate apps. We weren't guessing at what a small business owner needs from admin software. We were that small business, hitting that exact friction, on a Tuesday afternoon trying to get an invoice out before a deadline.

The South African context in Sorted Nexus (VAT handling, POPIA compliance) isn't a feature we added after market research told us to. It's there because we needed it ourselves, and because we knew from direct experience that most small business owners are learning tax and compliance rules for the first time while also trying to run a business, not studying them in advance.

The same pattern shows up in every other product we've put out. KeyForge exists because we were constantly reaching for a UUID generator or a quick encoding tool while writing code, and got tired of hunting through ad-heavy sites that felt unsafe to paste anything sensitive into. RunYourNumbers exists because working out what a bond repayment or a take-home salary actually looks like, using real South African tax brackets, is a question we'd asked for ourselves more than once.

Qrop came out of needing a QR code generator that didn't watermark the output or bury the download behind an account wall, and that could eventually scale into something an actual business could integrate through an API rather than generating codes one at a time by hand. Even Quiz Bru, which reads as the most purely fun product in the lineup, came from wanting to run a quiz for a group without wrangling slides, a separate buzzer app, and a spreadsheet for scoring.

Determine This is the one exception that proves the same rule from a different angle: it wasn't built from our own professional experience, but from watching, up close, how many marks students lose in Grade 10 to 12 Maths simply from misreading what an instruction word like 'determine' or 'hence' is actually asking for. Direct, specific knowledge of the problem again, just from a different vantage point than a day job.

The next product we're building follows exactly this pattern, in a domain that's further from what most people would expect from a studio that's mostly shipped consumer tools. Offloader is a stateless API for portfolio performance and risk metrics: time-weighted return, money-weighted return, Sharpe ratio, Sortino ratio, and the other calculations that fintech platforms and financial advisors need to run correctly and consistently.

It's built for South African fintech and advisor platforms specifically, because that's the environment where we've seen firsthand how much time and risk goes into getting these calculations right. Performance and risk metrics look simple in a textbook. In practice, getting time-weighted return right across irregular cash flows, or getting Sortino right when your downside deviation calculation has an edge case nobody documented, is exactly the kind of detail that either takes a specialist team months to build properly, or gets quietly approximated and never fully trusted.

A stateless API is the right shape for this problem on purpose. Advisor platforms and fintech products don't need us holding onto their portfolio data. They need a reliable calculation engine they can call with the numbers they already have and trust the answer that comes back, without adding a new place for sensitive financial data to sit. That constraint came directly out of understanding how these platforms are actually built and what they'd realistically be willing to integrate.

We're a small studio, and we don't have the resources to build something, get the details wrong, and rely on a large support team to smooth over the gap between the product and reality. That makes direct experience with a problem less of a nice-to-have and more of a practical necessity. It's the difference between guessing where the edge cases are and already knowing, because you've hit a few of them yourself.

It also means our roadmap isn't really a roadmap in the traditional sense. We don't sit down with a spreadsheet of market opportunities and rank them. We build what we've personally run into needing, whether that's an invoicing tool, a QR generator, or now a portfolio metrics API, and we trust that if the problem was real and specific enough for us to feel it, it's real for other people in a similar position too.

That approach has been right often enough that we're sticking with it for Offloader. We're not fintech outsiders building a calculator because the category looked profitable. We're building the tool we understand is missing, for the platforms we understand need it, because we've been close enough to the problem to see exactly where it hurts.