The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
I went through it as if I were a founder deciding whether to hire you. This is the version I would publish.
While testing Expirel as a public user, I identified a usability issue in the email verification flow that resulted in a confusing authentication error after successful verification.
I documented the issue with clear reproduction steps, expected behavior, actual behavior, and testing environment details before submitting it to the product team.
The team successfully reproduced the issue, acknowledged the UX concern, and later confirmed that the reported bug had been fixed.
This case study demonstrates my approach to identifying reproducible issues, communicating them clearly, and contributing to product quality through structured QA and UX testing.
If you’re building a SaaS, mobile, or Web3 product and want critical issues identified before your users find them, I’d be happy to help.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
I built ReviewIQ because technical interviews don't always test whether you can actually review code.
ReviewIQ is an AI-powered code review interview trainer built for software engineers.
You pick a role, language, and seniority, then get a realistic PR diff with bugs intentionally planted in it.
You write your review.
Then the system grades it against the actual bugs, shows what you caught, what you missed, and gives you feedback on how a stronger reviewer would approach it.
The interesting part was building the grading system so it isn't just "AI thinks your answer is good." The bugs have a known ground truth, so the review can be evaluated against something concrete.
Built with Next.js, Supabase, PostgreSQL, OpenAI, and Lemon Squeezy.
I'm interested in building more products where AI isn't just a chat box, but an actual part of the product experience.
The known-ground-truth approach is a great product decision—it makes the feedback feel earned rather than like an opaque AI verdict. I also like that the flow tests the actual review skill instead of rewarding pattern-matching in interviews.
Does someone on your team lose a day or two building the sales report every week or month?
That was the starting point at Mokobara, the premium travel brand. Pulling sales across all their stores, checking returns, reconciling the numbers and emailing each manager took 1 to 2 days every cycle, with 8+ hours of that spent just reconciling.
I built them an automation on Make.com a few months ago. It has run on its own ever since, weekly and monthly:
Make pulls every sales record from BigQuery, 100K to 250K per cycle. That is too many for one request, so it reads them page by page and stitches them back together.
It calculates the numbers the team actually uses: net sales per store after returns and discounts, return rates and the change against the last period.
It builds a CSV with the full breakdown and a short email summary you can read in 60 seconds.
It reads a Google Sheet of store representatives and emails every one of them the report for their own store.
The result: the reporting problem is gone. The report went from 1 to 2 days of manual work to fully automatic, and the 8+ hours of reconciliation dropped to zero.
Two things I would do the same way again:
Calculate "net sales" in the automation, not in the warehouse. The business rule for what counts as a net sale is not what the raw data stores.
Send people their slice, not the whole report. One report for everyone gets skimmed by everyone.
The figures in the image are placeholders, the real ones stay with the client.
What report is your team still building by hand? Tell me where the data lives and I will tell you how I would automate it.
I was handed a logo and a color palette. The client needed everything else — the system that turns a few brand decisions into a working enterprise product.
The project: a from-scratch redesign of an eIDAS-compliant B2B signature platform. Legally binding document workflows, enterprise customers, zero room for ambiguity.
I built the system in a deliberate order: icons → tokens → components → screens. Each layer constrained the one above it. That order is the whole method — by the time the first screen was designed, the system underneath was already stable. Screens demonstrated the system instead of driving it.
The token architecture had three layers: global primitives, alias tokens that describe intent (surface.primary, border.subtle), and component tokens that bind intent to elements. Sounds academic — until the team grew and other designers started building on top of my foundation. Some of my decisions held. Others got changed.
The token architecture absorbed both without breaking. That's the only test that matters.
A system that can't be changed isn't a system — it's a style guide.
Full case study — the setup, the build order, and three surfaces where the system did real work: bozenabulat.com/projects/b2b-signature-platform-redesign
bozenabulat.com
B2B Signature Platform Redesign
A token-based design system for a B2B signature platform built on an enterprise CRM. Turned inherited brand foundations into a scalable architecture.