The software we build for ourselves is up for grabs

We don't like wasting food, so we have a rule called Up For Grabs (UFG). If someone doesn't intend to eat their order, they post that it is UFG, and people who forgot to order can lurk on the food channel to claim it.

This worked for years, but eventually it started to feel pretty primitive. You had to remember what you had ordered and wait for someone to post. More questions arose too. Who forgets to order most of the time? Who grabs the most? What is the most popular dish this week? How much food are we saving?

Then we asked ourselves how fun it would be to build our own software around food ordering with analytics built in. How hard can it be with today's agentic development? The idea itself was not new, as it had come up for years and more than one of us had taken a jab at it before stopping at the sheer amount of effort involved, and compressing that effort is probably what finally made it a reality.

In this blog post we'll trace how agentic development has changed the way we build internal tools, from lunch ordering to the systems we use to run the company and the ideas that might eventually become products.

Our lunch system started as a simple Google Form. It did the job, but it lacked the features that the culture around the food had developed. We mostly used Slack for communication around food, yet we needed to go online to order. Our office manager posted on Friday to order once he received the menu. If you forgot to order you had to babysit the food channel to wait for food. All of these features had been solved organically in Slack and evolved in our culture, so we saw the opportunity to transform that into a digital feature within a new system that incorporated the best of both worlds.

The new system was a simple database with an API on top that interacted directly with our auth layer, while also allowing users outside the organization. Then we built two applications on top of the API, one for Slack and one on the web. The website serves as an administrative tool to review today's orders and upload new menus, while Slack includes commands such as /lunch to bring out the menu selection and /ufg to put today's order up for grabs. Given the integration capabilities we now get automatic reminders to order, and a nudge if we have forgotten to do so. These are just the highlights of the system: there are more features already in place and many more on the way, such as a UFG queue so you can be assigned food automatically instead of waiting to claim it.

After brainstorming over these ideas for a few days, implementation took about two weeks in total. There was no requirement phase, as we, the users, had already defined those over the years. This project was all about transferring our culture into a digital product. The best thing about it is that the solution lives in our internal code repository, so anyone can now implement a change that is available in production shortly afterwards. This gives us a product that is both visually and functionally more like Gangverk and less like generic software. After this successful lunch (as opposed to "launch", get it?), are there opportunities to apply the same methodology to other systems in use?

Food is fun and important, but so is time registration, employee administration and invoicing. In the early days of Gangverk, our engineering time went into client work rather than building software for ourselves. Furthermore, we had not built up the same experience with our own internal processes and the tools needed to support them.

Over time, as the company grew, we learned more about how we actually wanted to operate and where existing software did not fit. We found ourselves using multiple systems because one might handle A and B well but be poor at C, while another solved C but was weaker at A and B. None of them really reflected the full way we wanted to work. We were paying for multiple products yet still working around the gaps between them. So instead of waiting for new features, adapting our processes or buying a third system, building it ourselves became more interesting.

Today, tools such as time.gangverk.is and admin.gangverk.is are becoming part of that internal platform. Time handles time registration on projects, while the admin panel focuses on administrative work such as employees, projects and invoicing. In short, we can build the particular version of the workflows that fit us instead of paying for an unused set of features.

We sat down with Atli Þorbjörnsson↗, our founder and CEO, to talk about what changes when you stop waiting for features and start building them.

[Atli:] "Price increases were part of it, but the bigger issue was that we were using multiple systems to get the functionality we needed. We were paying for features that we weren't using. At some point we started questioning whether building a custom combination is the simpler solution."

[A:] "Cost mattered, but so did flexibility. Running separate systems made integrations difficult, and when the company wanted a change we were dependent on somebody else. If we needed an administrative feature that did not exist, we had to wait for the feature, adapt our process or buy yet another solution."

[A:] "There is probably an equation somewhere that solves whether it is cheaper to own or rent software. But it changes quickly when the foundations already exist and adding the next feature is relatively cheap. We are also moving further into operating software ourselves. We have always done that alongside development, but increasingly we can take on the ongoing operation as a service. That makes owning and continuously improving a solution a more realistic option than it used to be."

[A:] "How the software feels. It can be more welcoming and representative of the culture around the company. That sounds superficial until you remember that these are applications people might use every day."

[A:] "For the MVPs, yes. We know the tools available to us and have the experience to estimate the initial build fairly well. What is harder to predict is what comes after people start using the software. Employees quickly become customers, and new requests, edge cases and ideas start appearing. In that sense it is no different from client work, except the client can now add their own features to the software."

That kind of thinking has also carried over into the ideas we explore internally when people have some spare time. We keep those ideas in one place so they are not forgotten, and review them occasionally to see which ones are worth taking further. We call it 90210. People who are interested can then pick them up together to explore an idea that might have wider potential. There are currently 21 project ideas in the system and many are already well into development. A few are now interesting enough that we are exploring whether they could become products outside Gangverk as well.

This has also become a way to practise product thinking. We don't only focus on how to build something, but also what problem we are solving, who it is for, and what the MVP should look like. Since these are internal projects, the stakes are lower and there is more room to experiment. People still get to work with real users and their feedback, but in a safer environment. Our projects are therefore useful both for learning new technology and for learning how to turn an idea into a product.

At Gangverk, we also like to have regular fun like most other normal people. In our recreation room we have activities such as darts and computer games. We also have a foosball table that nobody was keeping track of the performance on. So of course we made an application to handle that. A simple leaderboard would have sufficed, but that is not the part of the work where product exploration and experimentation happens.

This led to one of our devs researching different ranking systems to find one that would fit. He ended up using a Glicko-2 rating with custom handling for team games and game history. He also implemented a network graph showing who plays against whom. The graph is definitely unnecessary, but given his interest in data visualization he wanted to learn how to build one. Which is partly the point. When there is room to experiment and innovate, not every engineering decision has to survive a sprint planning session to serve an immediate business case.

Sometimes we build something simply because we want to learn how it works, and maybe that technique becomes useful on an unrelated project later. Sometimes that results in a better lunch product, and sometimes it gives us an excuse to build a completely unnecessary foosball graph which also makes work and life more fun.

Agentic development has made these experiments much cheaper to run. Combined with the engineering experience we already have, that means we can move from an idea to a product people can actually use quite quickly. That makes internal tooling a useful place to experiment and to build something much bigger than we first intended.