Free doesn’t mean careless: a web app after a year in production

About a year ago we launched grounds-up.coffee, a tool for meetings and retros that actually reach an outcome. It deliberately breaks with almost everything that counts as mandatory when you build a web app “properly”. It costs nothing and always will, it asks for no sign-up, and whatever people type into it lives only as long as the purpose requires. By the usual maths, a product that earns nothing and locks in no users ought to cut corners everywhere else.

That was precisely not the plan. This is not our first application, and we know what a product needs that people use every day. What was new were two things: this application was built entirely with AI from the very first line, and it was meant to be free for good from the start. Neither was allowed to change the standards we apply to any production product for a client.

A product has to solve your problem, not collect your data.

A year in production was the honest test of that claim, and it confirmed a handful of decisions you can take for your own web app. What follows is not about the product, but about exactly those decisions.

Free was a decision, not a discount

Free and sign-up-free was not a question of price, but of friction: every hurdle before the moment a tool solves someone’s problem costs you usage, and an account is such a hurdle. That it never has to pay for itself comes down to one thing: we use it ourselves, in our work with clients. It eases that collaboration so noticeably that the running costs are carried by that value, not by an invoice. And many clients stay with it: they like the tool enough to keep using it for their own meetings, entirely without us.

From this follows the real pressure to keep standards high, and it is greater than for a paid side project. This tool sits in direct contact with our clients; it is a piece of our reputation. A security or privacy incident here would be no mere bug, but reputational damage at exactly the spot we live from. Free therefore does not lower the bar, it raises it. That a budget is less a number than a deliberate decision about how much risk you take where, we explore in a separate article. The question that carries the rest of this piece is therefore: how do you hold the highest standards with an effort that fits a product without direct income of its own? The sections below are the answers, one per decision.

No account, secure anyway

Picture someone who wants to start a retro with four people in two minutes and first lands on a registration form, then in their inbox, hunting for the confirmation email. Half the group is distracted before the meeting even begins. The obvious question: how can access be secure if we drop exactly that sign-up?

The answer starts by separating two things that often get lumped together. An account answers who you are over time. For a meeting, the only question that matters is whether you belong in it or not, and that can be answered without a lasting identity.

It works like this: whoever moderates creates a room and holds a key for it that lives only locally in their browser. Every participant is handed their own on joining, with no sign-up at all. Entry is then requested via the room key, and the moderator decides who comes in and who flies out again. The key itself is shared the way the group already communicates, over Slack, Teams, email or simply the video chat everyone is already sitting in. No account, no password, no email ping-pong before you finally get going.

So much for the idea, which transfers to many products. The real care sits underneath, in the places a user never sees.

It follows one principle you can apply to any web app: the browser is hostile territory, only the server decides. Anything running in the browser can be changed by the user, so nothing important may hang there alone. The clock that bounds a meeting phase therefore runs on the server, not in the browser, or you could grant yourself more time with one move in the developer tools. The moderator’s key only claims who they are in the browser; whether they may actually moderate is checked by the server every single time.

Once you have internalised this principle, you get most security decisions right almost by default. It is worth more than any single measure, because it explains why a login alone secures nothing: a login only answers who someone is, not whether the server double-checks on every action.

Data you cannot reverse-engineer

Every product faces the same temptation sooner or later: you want to understand how it is used, and the easiest path seems to be recording as much as possible. We wanted the opposite, to keep as little as possible. That sounds contradictory at first, because how are you meant to learn from usage without looking over your users’ shoulders?

A meeting tool inevitably sees what people write into it, and as long as the room is live those contents are stored too, so a restart does not destroy the session. The difference is what happens afterwards. Once the room expires, it is deleted along with its contents automatically, without anyone pressing a button.

What remains is pure statistics, built so that it cannot be traced back to a person. The moment a room disappears, we record how long the phases took and how many topics were discussed, but not what was discussed or by whom. Visits to the application are counted too, but the addresses that would give away an individual visitor have long since been replaced by neutral placeholders.

The surprising part is that this very restraint produced the clearer view. Because every room created leaves one anonymous dot in the statistics, you see the whole funnel: how many rooms were opened, how many actually started, and how many were carried through to the end. Where many drop out, something is wrong, and it shows up here without having watched a single person over the shoulder.

This data minimisation is not a privacy coat of paint applied afterwards, but a principle we work by anyway. We build and run our products on the principles of ISO 27001, even without a certificate on the wall. Collecting only what a feature truly needs, and getting rid of it once its purpose is served, is one such principle. That no revenue hung on the data made the decision easy, by the way: there was simply no reason to keep something we might later have wanted to make money from. The principle protects users, and in passing it protects us, because data that never piles up cannot be lost either.

The shortest path: feedback inside the product

When you measure anonymously, you do see that people drop out at a certain point, but not why. No analytics dashboard, however polished, closes that gap, only a short path to the people themselves. That is why the product has, from the start, a frictionless way to report a bug or a wish without leaving the tool and without hunting for a form on some other page.

In our view this is the single most important feature, and it should be the first thing you build, not the last. A direct channel back turns usage into a conversation. In practice a message like this often came in the morning and was out again within days as an improvement that then helped everyone, not just the one person who had spoken up.

This tight loop of real usage, direct feedback and quick improvement is something other than a roadmap drawn up once a quarter in a meeting far from the point. It keeps the product tied to reality, and it is the reason a small, free tool could mature over a year exactly where it pinched people.

A direct channel back turns usage into a conversation that becomes improvements within days.

Built with AI, from idea to deploy

A first working thing often comes together over a weekend now, with AI at every step: sharpening the concept, phrasing the requirements, writing the code, testing. This application came to life that way from the first line. But if building goes that fast, it begs the question why a product still takes months before you let it go live with a clear conscience. What is missing between “works on my machine” and “runs reliably for everyone”?

The answer is that the code was never the hard part. The hard part is everything that keeps it running reliably in production, and this is exactly where experience pays off that no model brings along. We have, as with any serious product, separate environments for development, for staging and for real operation, and a release runs through a pipeline that checks before it ships. AI speeds up every single step in there, but that these steps exist at all, and in what order they apply, is a decision you have to make and own yourself.

How this fast start with AI works, and how a deployment pipeline changes when AI joins in, we have described elsewhere. How you start small without overloading yourself, and what continuous integration in the age of AI means, two separate articles go into. Here only one point counts: AI lowers the hurdle to building, not the one to operating.

Keeping dependencies clean

Monday morning, the security scanner reports a vulnerability in a package buried somewhere deep in the dependencies. The reflex is to pull in the latest version quickly and move on, done. We have made a habit of pausing here and asking a different question first, and that habit has turned out to be one of the load-bearing ones.

Before updating comes an inventory. What purpose does this library serve, is it even still maintained, and do we use its full scope or only a small part of it? Often the honest answer is that it handles a trifle you could just as well write yourself, and then out it goes. If it cannot be removed, perhaps it belongs only in development and not in the shipped product, which takes it out of the line of fire. Your own code is not automatically safer than a library, but it is easier to review and to own in your own context.

That maintenance of all things is the deciding factor is no side note. Open-source libraries are wonderful, often holding a lot of knowledge and work no one sensibly wants to redo. That very same library turns into a risk the moment no one maintains it any more, because known holes then stay open and no one reacts.

An example from our own operation: to watch the licenses across our projects we long ran the tool license-checker. It has not been maintained for years, which you can tell from the fact that the community has split it into numerous forks. With that lack of maintenance it dragged known vulnerabilities along through its own dependencies, of all things a tool meant to ensure diligence. The consequence was a switch across all projects, and that is exactly the kind of decision an inventory triggers and a quick fix misses.

On top of that comes a firm eye on licenses: every library in use must be compatible with the product, and we have a standard for that which we apply consistently. It is unspectacular and often overlooked, but it is part of the same diligence. A clean dependency tree is not only safer, it is also more honest about what a product actually rests on.

Why this matters more in 2026 than ever

In the first days of operation something stood out in the access logs: a large share of the requests came not from users at all, but from automated scanners probing at random for known holes. That raises an uncomfortable question, precisely for a small, free tool that harms no one: why does anyone knock at all, at a product that should be no worthwhile target for anybody?

The answer lies in how fundamentally the threat landscape has turned. An attack used to need a target worth the effort, because behind the keyboard sat a human whose time cost money. A small, free tool was simply too unimportant to end up in the crosshairs.

That has reversed. Automation and now AI have pushed the cost of an attack per target down so far that it pays to simply probe the entire internet and take whatever responds. Security researchers describe how AI-assisted attacks drop the cost per target to a few dollars and thereby make mass attacks possible that used to be too expensive (Dark Reading, 2026). Whoever is online is a target, no matter how small or unremarkable.

How real this is showed late in 2026 in an unexpected place. In October and November, across the borders of many European countries, the internet-connected refrigeration controllers of hundreds of supermarkets were attacked, temperatures turned up, goods spoiled (Palo Alto Unit 42, 2026). No one was after a particular branch. Being vulnerable and reachable was enough, and researchers found thousands of such controllers open on the net (Euronews, 2026).

Against this kind of pressure no large security team helps, but a sober way of building does. The application sits behind several layers, each with one job: a fronting CDN with a web application firewall catches the crude nonsense far out. Behind it a load balancer takes the connections and rebuilds them before anything reaches the container. And the container itself runs on a deliberately minimal, up-to-date base image that offers barely any attack surface.

That the load balancer terminates the connection is more than a technical detail here. A request passes through many layers, IP, TCP, TLS, HTTP, the headers, and each of them potentially holds a flaw. Because these layers are resolved and cleanly rebuilt at the CDN and the load balancer, the container never sees a raw connection from the internet, only vetted, well-formed traffic from its own network. Nothing can ever be fully ruled out, but the likelihood of actually exploiting something at this level becomes very small. What remains is the application layer, and that is exactly where the clean dependency tree and the firewall in front of it take hold.

And because mass comes automated, what counts most today is speed. The answer to those scanners from the first days was therefore not a human intervening at night, but a rule that locks out a suspicious address on its own for a while, together with regular, automatic checks that run anyway. Keep the attack surface small and react fast and automatically: both are again leaving things out and prevention, not arming up.

The interface is allowed to mature

Amid all the care over security and operation, one spot deserves some relief. The interface did not have to be perfect at launch, and it was not. Where security and privacy must stand from day one, because a mistake there is expensive and hard to heal, the feel of an interface may grow over time.

That is exactly what happened. Many of the small improvements to guidance, labelling and flow came from the direct feedback and from the anonymous view of where people hesitate. An interface that matures with real usage is in the end a better fit than one perfected in advance at the drawing board, and it relieves a great deal, because not everything has to be finished at once.

A small example shows how it plays together. That every input is checked server-side was set from the start, and not only on content but also on the length of a field. What was missing at first was the feedback to the person in front of it: the server refused an over-long input only after someone had already typed their fingers off. The maturing then lay not in a new rule, but in a plain “321 of 500 characters” right in the field, derived from the very limit the security check already knows.

The real work was not that one counter, but carrying it through consistently for every field, so the interface promises everywhere the same thing the server ultimately enforces. That way the check stays where it belongs, namely on the server, and the person still learns early where they stand. A trifle in the result, but exactly the kind of maturing that real usage surfaces and that you rarely have on your radar beforehand.

Security tolerates no delay, the interface is allowed to mature.

What you can take away

A year in production boils down to a handful of decisions that suit almost any web app, not just a free one. They are an offer, not a rule, and no one has to put them all in place at once.

Seven have proven themselves especially:

• Question the login: for every sign-in, be clear what question it really answers, and skip it where a random, secret access key is enough.
• Keep data lean: collect only what a feature truly needs, and delete it again once the purpose is served.
• Measure anonymously: capture usage so that the hurdles become visible, without touching the real data.
• A short path to the user: build the direct feedback as one of the first features, and shape the internal workflows so that a quick change is possible.
• Inventory your third-party code: for every library in use, be clear what purpose it serves, whether it is still maintained, and whether you use its full scope or only a small part.
• Keep the attack surface small, and prefer reacting automatically and at once over heroically by hand.
• Let the interface mature, while the things that are hard to heal are in place from the start.

Most of this is not extra effort, but a different order and the courage to leave things out. That is exactly what turns “free” from a cost-cutting exercise into a deliberate, clean way of building.

What we actually learned

The most surprising insight from this year is that almost nothing that carried the product costs more than a decision made at the right moment. Not building a login is cheaper than building one. Not collecting data is cheaper than protecting it. Laying the path to the user early is cheaper than guessing later why no one stays. Whoever waits until a product is “important enough” for diligence ends up building the expensive version. The diligent version is the cheap one, if you choose it early.

That we could see this so clearly came down to a deliberate choice from the start. We wanted the product because it helps us and solves a real problem, but not at any price. The operating budget was therefore defined quickly and tightly, while the development effort was deliberately not capped, yet also not treated as a side hobby, but held to one clear mandate: evaluate and act on client feedback fast. This combination, a tight operating frame and determined development with a short path to the user, is what forced each of the decisions above in the first place.

The diligent version is the cheap one, if you choose it early enough.

And one more thing the year showed: 2026 was no quiet year to be online. The tools you build with today are the same ones others attack with, and both have become faster and cheaper. That is exactly why a way of building that offers little surface and reacts fast carries further than one that bets on size and retrofitting. Less, here, is not the frugal choice but the robust one.

We do this every day, for our own products like Grounds Up and for clients whose product really has to carry in production, from the clean way of building to readiness toward an ISO 27001 certification.

If you want to know where your own web app stands on exactly these points, we go through it with you in a health check: access and data handling, dependencies and attack surface, operation and monitoring. At the end you have an honest assessment and a manageable list of next steps, ordered by impact.