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..
Really cool product! Moving brand guidelines from a static PDF/Figma file to live enforced rules inside an editor is a smart move.
The problem is crystal clear. Hope you get actionable feedback from the demo—here’s to landing that first customer very soon! 🥂
Thanks! Really appreciate that. Turning the guidelines into something people can actually follow while creating was the main idea behind Rectiva. Hoping the demo helps me learn what to improve next.
The origin story makes sense, and I like that you narrowed the problem from brand consistency to reducing interpretation during production.
For the beta, I would test one real asset end to end with a local team: can they create, review, and approve something without needing a separate explanation of the rules? The most valuable signal may be where they hesitate, not whether the demo looks impressive.
What is the first workflow you want a beta user to complete without your help?
There are actually two workflows I want to test. First, whether a brand admin can turn their existing guidelines into templates and review rules without my help. Then, whether a local team can use that setup to create, review, fix, and export an asset without going back to the guideline document.
I think the second workflow is ultimately the one I care most about, but the first has to work well for that to be possible. Your point about watching where people hesitate is really useful for testing both.
I like the override approach, but I’d be careful about treating override frequency alone as the signal.
A rule being overridden 40% of the time could mean very different things:
I’d require a lightweight reason whenever someone overrides a Critical violation.
Something like:
false positive / approved exception / rule unclear / guideline outdated / otherThen store the rule version, asset type, market/team, and who approved the override.
That turns the override log into a feedback system for the brand admin rather than just an audit trail.
You could eventually surface things like:
“Rule 17 has been overridden in 38% of APAC assets, mostly as approved exceptions.”
At that point the admin has evidence that the problem may be the rule itself, not the creators.
I’d also consider setting an override threshold where repeated exceptions trigger a rule review instead of continuing indefinitely.
Are you currently capturing why someone overrides a violation, or only that the override happened?
Right now it's the latter. If the user proceeds after the confirmation dialog, the export is simply marked as "overridden" in the admin's content log. So it's an audit trail, not a feedback system, exactly as you put it.
The reason taxonomy feels like the missing piece. Without it, the same override rate could mean completely different things and I wouldn't know why. I especially like approved exception, since regional adaptations are a very real use case for global brands.
Keeping the reason selection lightweight, maybe just one tap, also makes a lot of sense. Thanks, this gave me a much clearer idea of how the override log could become useful beyond just recording what happened.
Glad it helped.
I think the lightweight reason taxonomy is the key part — enough structure to tell false positives, legitimate exceptions, and outdated rules apart without turning every override into paperwork.
Once you have a bit of real usage, the patterns in those reasons should tell you much more than the override rate alone.
Good luck with the implementation.
Thanks again! I really like the idea of keeping it structured without making it feel like extra paperwork. I’ll keep that balance in mind.
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.
That makes sense. I think the distinction I need to be more careful about is whether the rule itself can actually be judged objectively, not whether it’s checked by code or AI. I’m leaning toward keeping that category pretty narrow early on and flagging the more ambiguous rules for human review instead. Thanks, this gave me a much clearer way to think about it.
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.
Thanks! That's exactly how it started. It was one recurring headache from a real project, not a "platform vision." Still trying to keep that discipline as I add features.
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.