I turned a real client problem into a B2B design tool
I’m a designer, and I recently launched a free beta of a product called Rectiva.
The idea came from a problem I encountered while working at a design agency.
One of our clients was a global brand with local marketing teams across four countries in Asia. HQ already had detailed brand guidelines and even tracked compliance through KPI reports, but the content produced across local markets was still inconsistent.
They came to us asking how they could make brand execution more consistent across regions.
My first attempt was to make the guidelines easier to apply in production. I designed Figma templates covering different channels and sizes for the local teams to use.
But the consistency problem was still there.
That made me wonder whether one part of the problem was that, even with guidelines and templates, many brand rules still depended on whoever was creating the content to interpret and apply them correctly.
I later asked people in r/DesignSystems why this happens across global teams. The answers were varied — local market needs, weak enforcement, rigid guidelines, ownership, training, and creative freedom all came up.
So I stopped thinking of it as a single-cause problem.
Instead, I decided to focus on one part I could actually build for: reducing how much brand compliance depends on someone remembering and manually interpreting the guidelines while creating content.
That became Rectiva.
Rectiva is a web-based design editor. Structural rules can be built directly into templates, while things that require visual judgment can be reviewed against plain-language rules defined by the brand admin.
For example, a brand can define rules such as “the product must not be cut off at the frame edge,” or check whether a logo has enough contrast against its background.
The product is working now, but I’m still very early. Finding the right users has been harder than I expected, and before I spend too much time thinking about distribution, I’d really like some honest feedback on the product itself.
If you try the demo, I’m especially curious about three things:
- Is it immediately clear what problem Rectiva is solving?
- Does the way I’m solving it make sense, or does anything feel unnecessary or overcomplicated?
- Is there any point in the demo where you lose interest, hesitate, or wonder why you would need this?
Feedback on the positioning or where you’d look for early users would also be really useful, but product feedback is what I’d value most right now.
No-signup demo:
https://rectiva.io/demo
Free beta:
https://rectiva.io
Anyway, here’s to finding my first customer..
The reframe that stands out: you didn't make the guidelines clearer, you moved compliance out of memory and into structure. I did the same move for a different kind of consistency problem. Building Alisio, I could have written a guideline for the AI I direct, like "try to keep Facturado and Cobrado close if they're nearly equal," and trusted it to interpret that sensibly. Instead I made it structurally impossible for those two numbers to ever merge into one, full stop, no judgment call available. The objective-vs-subjective split in the comments is the right question to push on, because that's exactly where templates keep failing silently: the moment a rule needs interpretation, someone will interpret it differently under deadline pressure, no matter how detailed the guideline was. I'd rather see Rectiva be aggressively narrow about what counts as objective early on than generous, since a false "this is objective" call is worse than flagging too much for review.
This is probably one of the better ways to find a B2B product idea. When the problem comes from an actual client, you already have some evidence that it's painful enough for someone to spend money solving it.
I also like that you didn't try to build a huge platform from day one. Starting with the specific workflow that was causing the headache makes a lot of sense. If you can remove that one frustrating part really well, the rest of the product can grow from there.
The insight that lands here is that templates didn't solve the consistency problem because you were measuring the wrong thing. You measured "did we make guidelines easier to apply" when the real measurement was "are the rules actually being followed in production."
Templates require interpretation. That means the measurement system is "did the creator understand and execute correctly" - which is fragile across teams, regions, and people. An editor that encodes rules directly inverts the measurement: "did the system enforce the rule, even if the creator didn't have to think about it?"
That shift from "how do we make guidelines clearer" to "how do we make guidelines execute automatically" is really a shift from measuring compliance as a training problem to measuring it as a structural problem. Same guidelines, completely different measurement system.
The harder part you're going to run into is when rules require judgment - like "contrast must be sufficient" is objective, but "the brand feels heavy here" isn't. You can encode the first. The second still depends on whoever's reviewing knowing what "heavy" means in your context.
But that's actually useful to measure separately. Once you have the structural rules working, "which decisions still require human judgment" becomes a much clearer question. You can then decide whether to train people on those, build new structural rules, or accept that some things just need a human eye. The measurement system you've built lets you see exactly where that boundary is instead of guessing.
This is a really helpful way to frame it. The distinction between structural rules and judgment-based rules is very close to how I'm thinking about Rectiva.
One decision I made around that was not to completely block export even when a Critical violation is detected. Instead, Rectiva shows the violation again before export and asks the user to explicitly confirm if they still want to proceed. My thinking was that the system should catch and surface potential violations, but not always make the final decision — especially when some rules involve context or judgment. Those overrides get logged, so over time I can look at which rules are being overridden most often — which could help reveal where human judgment still tends to come in.
I'm curious what you think about that approach. Do you think that's the right balance, or would you expect certain rules to block export entirely?
The interesting part is that templates didn’t solve the consistency problem because they still left interpretation with the person creating the asset. That seems like the harder problem to solve, especially when local teams need some freedom rather than rigid templates.
That’s a good point. Templates can control things like logo or text placement, but image usage often depends on each company’s brand guidelines, so templates alone can’t cover everything.
That makes sense. It sounds like the harder problem isn't standardizing the asset itself, but translating each brand's guidelines into something the tool can apply without taking away the team's creative flexibility.
The part about reducing reliance on people remembering and manually interpreting guidelines really stood out to me. It feels like you’re solving the gap between “the rules exist” and “the rules actually get followed in production.” Curious to see how this holds up when teams have rules that require more subjective judgment.
Thanks for the thoughtful comment! Rules that require subjective judgment are definitely the harder part.
For now, I’m focusing on brand consistency and trying to keep the review criteria as concrete and observable as possible. Since brand admins can define the AI review rules in plain language, they can also make the criteria more specific when a rule needs more context, which gives the review a clearer basis for making a judgment.
Of course, there’s still a limit to how reliably something highly subjective can be evaluated, so figuring out where that boundary should be is something I’m still exploring.