60 days from first commit to Google indexing. Here's what I built,
what stack I chose, and what actually slowed me down.
What I built
QRflows is a dynamic QR code platform. The core idea: QR codes you
can edit after printing, with real-time scan analytics, Smart Rules
routing, and landing pages — all in one dashboard.
Sounds simple. The execution was not.
Why Laravel + React
I needed something that could scale without becoming a mess at
50k users, but also ship fast enough that I'd still be alive by
launch day.
Laravel handles the backend — API, auth, queue jobs, database.
React handles the frontend — the dashboard, QR builder, analytics
views. They communicate through a clean REST API.
This separation matters. When the frontend needs to change, the
backend doesn't care. When the backend logic gets complex, the
frontend stays simple. Scalability isn't just about servers — it's
about not painting yourself into a corner architecturally.
The hardest part
Getting the UX and architecture to work together without
compromising either one.
It's easy to build something scalable that's painful to use. It's
easy to build something beautiful that falls apart under load.
Getting both right at the same time — that's where the 60 days went.
Specific example: the QR builder. It needed to feel instant and
intuitive for non-technical users, but under the hood it had to
handle 16 different QR types, each with different validation rules,
different output formats, and different downstream jobs.
The solution was a clean abstraction layer in Laravel — each QR type
is its own class with a shared interface — combined with a React
component that adapts its form fields dynamically based on the
selected type. No spaghetti. No special cases everywhere.
Analytics that actually tell you something
Most QR tools show you a scan count. That's it.
I wanted analytics that suggest what to do next — not just what
happened. So the dashboard shows engagement score, scan consistency,
peak hours, and actionable recommendations.
One feature I didn't plan but users needed
A/B testing for QR codes. One printed code, multiple destinations,
weighted traffic split.
Turned out marketing teams using physical materials needed this badly
— they couldn't run experiments without reprinting everything.
What I'd do differently
Start with fewer QR types. I launched with 16. I should have launched
with 5 and added the rest based on what users actually needed.
Premature completeness is just as dangerous as premature optimization.
Where it is now
QRflows is live at qrflows.app. Free trial,
no credit card. Still early — but indexed, shipping, and getting
first users.
If you're building something similar with Laravel + React I'm happy
to compare notes. What's your biggest architectural headache right now?
Top comments (0)