A student founder's practical lessons from creating ProQR
A student can spend months improving a program that nobody outside a classroom ever uses. Publishing a real product changes the questions. The code must work for people who did not watch you build it. They will click the wrong button, try a phone you do not own, or simply leave when something takes too long.
I am David Mariscal Fernández, a student developer from Spain and the creator of ProQR, a browser-based QR code tool. This is not a story about a dramatic startup exit or a proven business model. It is about the difference between getting a project to run and making it useful enough for strangers to return.
ProQR began with a straightforward use case: someone wants to create a QR code, personalise it, and put it on a printed item or a screen. That can sound too simple to become a substantial technical project. The complications appear when a user wants to change a printed code’s destination, organise multiple codes, or understand what happened after a scan.
A static QR code embeds the information directly. If it contains a website address, that address is fixed within the pattern. A managed dynamic code contains a redirect URL: the printed pattern stays the same while the service can change the eventual destination. The dynamic method creates flexibility, but it introduces ongoing dependencies on the redirect service and its domain.
This distinction was more valuable than simply adding another colour picker. Product development became a matter of helping users understand a real trade-off, not offering the largest possible feature list.
If the product asks a new visitor to register before they can see anything useful, that extra step needs justification. ProQR’s public creator lets a visitor generate and download static codes without making account creation the central experience. Features such as saving codes, using dynamic links, or viewing analytics may need an account.
I learned to focus on the first minute: Can someone identify the input type? Can they produce a QR without reading documentation? Can they see that their design remains scannable? Does the download give them a usable file? A feature that exists in code but cannot be discovered in the interface is not much of a feature for the visitor.
My earliest instinct was to treat “implemented” as equivalent to “finished”. Testing changed that. A feature is not complete just because it works along the route I expected. It also has to survive ordinary mistakes, slow connections, screen-size differences and a user who does not know the names of the settings.
QR codes are physical interfaces in many contexts. They might be printed on menus, signs, packaging or flyers. A stylish design that fails to scan is worse than a plain one that works. High contrast, adequate white space around the code, logo size, print size and the actual material all matter.
ProQR allows visual customisation, but that creates a responsibility to test the output. A preview on a large monitor cannot guarantee success under indoor lighting or on low-resolution print. The practical discipline is to test generated files on different phones and at intended print sizes instead of assuming that aesthetically pleasing means technically reliable.
The same principle applies to downloads. The user needs a result they can use outside the app. Export format matters because an image for a website and artwork for a printer may have different requirements.
Dynamic QR codes can create scan-event data because the destination goes through a service-controlled redirect. Yet a scan count is not a count of unique customers, purchases or signups. A person may scan twice; a scanning app may preview a link; someone may reach the landing page and leave.
Building analytics forced me to separate observable events from business outcomes. A log of redirect requests is a useful operational measure, but a business should evaluate later actions with appropriate consent and measurement. Country or device information can also be unavailable or approximate. An “unknown” value is sometimes the most accurate result.I have investigated this kind of data gap in ProQR. I would rather identify a limitation than fill a dashboard with certainty the system has not earned. That choice is less exciting to market, but it gives the product a better technical foundation.
A static code stored in an image is largely independent of its creator once the destination is encoded. A managed dynamic code continues to depend on the availability of a link-management service. That changes the engineering priorities. Redirect speed, stable URLs, sensible error handling and data migrations matter, even if users never see the code that implements them.I also learned not to adopt a technical fix just because its name sounds right. If one hosting dashboard shows geographic information but a function does not, the difference may be about where each observation is recorded. Forwarded network headers involve trust boundaries and platform-specific behaviour. A fix should be tested on the real deployment rather than assumed from another system’s documentation.
Start small enough that you can explain the value in one sentence, then make the first experience genuinely usable. Write down the assumptions that would make the product fail. Speak to or observe real users, but distinguish compliments from repeat usage. Do not quote unverified totals as evidence of success.
Be willing to maintain unglamorous areas such as redirects, error messages, privacy choices and export quality. They create a disproportionate share of the experience people actually depend on. Keep public claims consistent with the features you can demonstrate today. If something is experimental or incomplete, describe it that way.
The biggest change was psychological. A class assignment ends when it is graded; a public web application remains available when its creator returns to schoolwork. That means deciding what can be supported sustainably, what should be simplified and when a new feature is less important than repairing an existing one.
Building ProQR has been a practical education in trade-offs, product communication and verifying assumptions. It does not prove that every student should start a SaaS business. It does show that a small public tool can teach lessons that a private prototype cannot.
David Mariscal Fernández is a Spain-based student developer and creator of ProQR.
Website: https://useproqr.com
This is a firsthand account of building the product, not a claim of financial success, customer conversion results or verified growth.