What Pain-Point are you Solving and How did you discover it?

I’m building VAT Engine to solve the fragmentation around cross-border EU VAT.

The problem is not simply finding a country’s standard VAT rate. The correct treatment can depend on the destination country, product category, supply date, customer context, thresholds, sales channel, and reporting scheme.

Smaller e-commerce and SaaS teams often end up combining spreadsheets, generic tax APIs, separate platform plugins, and manual accountant work. The calculation happens in one place, transaction evidence is stored somewhere else, and OSS reporting becomes another separate process.

I discovered the depth of the problem while researching how official EU VAT data could be turned into something developers could actually use reliably. The official data exists, but it needs normalization, historical validity handling, merchant-friendly product classes, and a clear connection between calculation and reporting.

VAT Engine turns that into one workflow: official EU rate data, historical lookups, exact VAT calculations, transaction evidence, threshold monitoring, and OSS/IOSS reporting preparation.

It is currently in alpha, so I’m still validating which parts create the most value for real merchants, developers, and accountants. The main thing that has stayed consistent is the belief that VAT calculations should produce reusable compliance evidence—not just return a percentage and disappear.

VAT Engine

I found the problem the same way most people do, by living inside it first. I was running three businesses at once, a software company, a care home, and until recently a cafe, and I was the one holding all of it together in my head. Not a dashboard, not a system, just memory and a running mental tally of what needed attention that day.

The signal was not one big moment, it was a pattern. I kept catching the important thing late. Not missing it entirely, catching it a day or two after it actually needed me, which in a business is often the same as missing it. I started asking other founders running more than one business if that felt familiar, and it did, almost every time.

Has it stayed true to the original idea? Mostly. The core problem never changed, knowing what actually needs you right now across everything you run. What evolved is how careful the answer has to be. Early on I underestimated how much founders needed to trust the answer, not just receive it, so a confidence label became as important as the alert itself, whether something is Verified, Very Likely, Needs Review, or Monitor Only.

What surprised me most is that I did not actually test this on a spreadsheet or a mockup. I tested it for months on a real small business, Bird's Nest Cafe, before I trusted it enough to build it out further.

FounderFlow is your AI Executive Chief of Staff. It watches your business, identifies what matters, protects your revenue, and tells you exactly what to do next. Right now I am inviting in the first 30 founders personally instead of opening it up to everyone.

Curious how you are validating that people would actually pay to have less on their plate, versus just agreeing that the problem is real.

The honest version of ours:

How I found it: I run AskCodi. We watched ~400k people who'd used us churn out — mostly to Claude Code and Codex. That stung, but it was the signal. They didn't leave because the terminal agents were bad. They left, then spent their days juggling sessions, picking models, hitting rate limits by lunch. The pain moved, it didn't disappear.

The signal it was worth solving: I caught myself doing it too. I was the bottleneck in my own workflow — deciding which tool, which model, re-prompting, babysitting. The tools weren't slow. I was the slow part.

Validation: the gap was already visible. Some people ship 5 PRs a day, some hit a wall by noon — same tools. The difference was purely how well they orchestrated them. That's a paid problem, because tokens are money and iterations are time.

Did it evolve? Completely. AskCodi used to be a place to pick from a menu of models. Now it's one agent that makes those picks for you and drives Claude Code / Codex / skills underneath. We stopped selling choice and started selling not having to choose.

Biggest surprise: the win wasn't a better model. It was removing a human decision. Routing to the right model cut tokens ~50% — but the real unlock was people just… thinking again, instead of managing agents.

We're live on PH today if the problem resonates → https://www.producthunt.com/products/askcodi/launches/askcodi-3

As a travel journalist for about a decade, I saw the same press trip frustrations play out, such as journalists not getting invites for press trips despite solid bylines, or getting flooded with irrelevant ones. We’re also often repeating the same info to organizers about our preferences, non-negotiables, dream trips, and editorial sweet spots. I personally spent upwards of seven hours last calendar year responding to invitations for trips I couldn't go on.

Simultaneously, trip organizers spend weeks on media list-building and struggle to find out the logistical, editorial, and human factors that determine whether someone is a fit for a press trip. So, I built Press Trip Pros.

With this database, trip organizers can find the right travel media for their press trips in minutes, not weeks, and travel media can make themselves discoverable for the types of press trips they want.

Launching today on Product Hunt if anyone would like to know more: https://www.producthunt.com/p/press-trip-pros/press-trip-pros

I started Blink Ideas from a pretty simple frustration: coming up with a business idea is easy, but figuring out whether it’s actually worth pursuing is hard.

I’d see people talking about problems on places like Hacker News, Reddit, Stack Exchange, app reviews, etc., but there wasn’t an easy way to systematically connect those complaints into potential opportunities.

The signal for me was that the raw material was already everywhere. People constantly describe things they hate, workarounds they use, and problems they wish someone would solve. The hard part is finding the patterns.

That led me to build Blink Ideas, which scans conversations and reviews across the web, identifies unmet needs, and ranks potential business opportunities based on things like pain, market appeal, scalability, and evidence.

The product has definitely evolved from the original idea. The biggest surprise has been how much harder distribution and validation are than actually building the product.

My biggest takeaway so far: finding a problem is only half the battle. You also need a reliable way to find the people who have that problem and determine whether it’s painful enough for them to actually do something about it.

https://blink-ideas-web.onrender.com/

• How did you uncover the problem you decided to work on?

Been dealing with different APMs for ages, realized they are expensive and always miss that one feature or trace that i needed
• What signals told you this problem was worth solving?

So many apps rely on Ruby on Rails, so many developers especially in larger teams forget about performance
• How did you validate (if at all) whether people would actually pay for a solution?

I built it thinking my current freelancer contracts would be interested, was not wrong.
• Has your product stayed true to the original problem, or did it evolve into something different?

It's still on the same path, a focused ruby on rails APM.
• What surprised you the most along the way?

How difficult it is to even get to showcase your product, even if it's a good one

Problem & Solution importance

Our starting point was something both personal and professional for me. As a non-native speaker of English, I am always anxious to post in public or send important messages to people abroad. I am also a linguist, so professionally I understand that words can have different meanings in different Englishes and that Englishes can be quite different from each other.

One more thing I understand both as a linguist and simply as myself is that the way we talk or write and the dialects we use are all parts of us and our identity. So sometimes it feels really awkward to replace our own words with automatically 'corrected' versions.

Our product - WIT explores how a message may be understood across American, Indian and Singapore English without replacing the writer’s words and voice, just suggesting the versions and possible cross-language mismatches.

Willingnnes to pay

As for willingness to pay, we have not validated that yet. The version we launched is our first prototype, and we are currently trying to talk to our users and understand what the next steps should be.

What surprised us the most so far?

The biggest surprise has been the feedback. One piece of early feedback looked at the product from an angle we had not thought about. Checking a message you received that felt ambiguous or off to learn whether there might be a mismatch in understanding because of differences across Englishes. We had focused mainly on outgoing messages, but this use case feels incredibly natural and may shape what we build next.

We would be really grateful for more feedback from the community!

https://www.producthunt.com/products/wit-will-it-travel

mine came from watching UK renters and leaseholders get stonewalled on repair complaints, damp, mould, that kind of thing. the actual bottleneck wasnt writing the complaint, most people can explain whats wrong in a paragraph. its knowing which legal framework and escalation route actually applies and citing it properly, thats the bit that makes a housing association or letting agent take a letter seriously instead of filing it.

i built complaintforge.com around that. free analysis first so someone can see if they actually have a case before paying anything, then a flat fee per letter rather than a subscription, because nobody wants a recurring charge for what should be a one off problem. its live but young, no real idea yet whether the pricing survives contact with volume.

the surprise so far is how much of the work is picking the right escalation path rather than the writing itself. the letter is almost the easy part once you know which ombudsman or regulator has jurisdiction

Disclosure, I built this. ComplaintForge came from watching how much friction sits between someone having a legitimate complaint and actually writing one that a company or an Ombudsman has to take seriously. UK consumer and tenant complaints have a specific shape, there is usually a real legal right underneath the frustration, but most people either give up or write something too emotional to be actionable.

The signal that it was worth building was not a survey, it was watching how many people search for template complaint letters and get generic boilerplate that ignores the specific regulation that applies to their situation. That is a narrow, structural gap rather than a vague one, which made it easier to validate than most SaaS ideas I have looked at.

Where it evolved from the original idea: I assumed the hard part would be the letter itself. It turned out the harder part is what happens after the first letter gets ignored, which is why it now also handles the escalation stage rather than stopping at send. People do not pay for a letter, they pay for not having to figure out the next step alone. It is live if anyone wants to see how the escalation pack is structured, happy to share the link if useful.