An account of building, launching and improving a free platform for static and dynamic QR codes while studying in Spain.
Building a product is very different from having an idea.
An idea can sound good in a few sentences. A real product has to work when someone else opens it, clicks the wrong button, uses it from a phone, comes back days later, or tries something you never expected.
That difference is what I learned while building ProQR.
I am David Mariscal Fernández, a student in Spain, and I created ProQR as an independent project. ProQR is a free web platform for creating and managing static and dynamic QR codes.
The project started from a simple question: why should creating a useful QR code feel more complicated than it needs to be?
QR codes are everywhere. They are used in restaurants, posters, packaging, events, business cards, classrooms and advertising campaigns.
Creating a basic QR code is easy. The interesting part begins after that.
A static QR code that contains a URL stores that URL directly. The data encoded in a printed static QR code cannot be changed, so using a different destination normally requires a new code unless the original URL can itself be redirected.
A dynamic QR code works differently. It uses a redirect that can be managed separately from the printed code, which means the destination can be changed later without changing the QR image.
That distinction becomes useful very quickly. Imagine printing hundreds of posters and then discovering that the destination URL needs to change. With a static QR code, you may need to reprint the codes. With a dynamic one, the destination can simply be updated.
I wanted ProQR to make those capabilities accessible through a straightforward interface rather than turning something simple into a complicated workflow.
ProQR allows users to create both static and dynamic QR codes in a browser.
Users can customize their codes, organize them, duplicate them and download them in formats suitable for different uses. Dynamic QR codes can also provide information about scans, including the device type, browser and approximate country.
The platform includes tools for organizing QR codes into folders and managing visual branding, which becomes increasingly useful when someone has more than a handful of codes.
The goal was not to add features simply to make the product look larger. The goal was to make the workflow practical from the moment someone creates a QR code to the moment that code is actually being used.
One of the biggest surprises was discovering that building the software was only part of the work.
A product can work perfectly in your own testing environment and still reveal problems as soon as other people begin using it.
Small interface decisions suddenly matter. Does the QR code look good on a phone? Can somebody understand the difference between static and dynamic without already knowing how they work? Is an important button obvious enough? Does the same workflow behave correctly after refreshing the page?
Those questions are difficult to answer while you are building because you already know how everything is supposed to work. Users do not. That makes outside feedback extremely valuable.
ProQR did not appear fully formed. There were bugs, design changes and technical decisions that needed to be reconsidered.
At one point, I discovered that some dynamic QR codes could bypass the tracking flow that was supposed to record scans correctly. The codes still redirected, so the problem was not immediately obvious from simply testing whether a QR code opened its destination.
That kind of bug taught me an important lesson. Testing whether a feature appears to work is not enough. You have to test whether every part behind the visible result is working too.
I fixed the issue and continued testing the product from the perspective of someone who had never seen it before. The mobile interface also required repeated adjustments. Something that looks balanced on a desktop screen can feel completely different when the available width is reduced to a phone.
Those problems were frustrating, but they were also probably more useful than the parts that worked immediately.
Before launch, most questions are technical. After launch, many of them become human.
How do people discover the product? Why does someone visit but not create an account? Which feature makes sense to me but confuses another person? What makes somebody return? How do you explain the product in one sentence without making it sound like every other QR tool?
Building software gives you a product. Distribution determines whether anybody knows that product exists.
I have spent a significant amount of time contacting people directly, asking for feedback, submitting ProQR to relevant websites and trying to understand which explanations actually make people interested enough to test it.
Some people respond. Many do not. Some are interested but want payment for coverage. Others give useful criticism. That process has made me think about ProQR less as a programming project and more as an actual product.
The first lesson is that finishing the code is not the same as finishing the product.
The second is that users will find problems you did not expect.
The third is that feedback is only valuable if you are willing to change something because of it.
It is easy to ask people what they think. It is harder to discover that something you liked is confusing and then remove or redesign it.
I have also learned that being a student does not lower the standard people expect from the product. If something is broken, it is broken. If the interface is confusing, the fact that the creator is a student does not make the interface clearer.
That is useful pressure. I would rather have ProQR judged by whether it works than by my age.
ProQR is already available publicly, but I still consider it a product in active development.
The next stage is less about adding a large number of features and more about improving the parts that determine whether people actually stay. That means continuing to improve usability, reliability and the experience of managing dynamic QR codes over time.
It also means listening closely to the people who use the product for something real.
There is a major difference between somebody saying that a project looks interesting and somebody depending on it for a printed QR code that cannot simply be replaced. The second person exposes the weaknesses of a product very quickly.
That is the kind of feedback I want.
David Mariscal Fernández is a student in Spain and the creator of ProQR, a free web platform for creating and managing static and dynamic QR codes.
