Makromatur

What is Makromatur?

Like many others, I decided to try to live a slightly healthier life. In the summer of 2025 I started going to the gym regularly and naturally became more interested in eating better and finding healthier recipes. But I kept running into the same problems. The recipes were often hidden behind long blocks of text, the units of measurement were awkward, some ingredients weren't easy to get in Iceland, I couldn't easily change portion sizes, and there was no convenient way to save the recipes I liked in one place. After complaining about this regularly to my brother, who is very interested in fitness and nutrition, he told me about his idea of publishing a recipe book and selling it in stores. I suggested that instead of starting with a traditional book, we could build a simple website with gated access to his recipes. The idea was to solve all the problems I had been running into myself and build a better experience around the recipes. And that's when things really got going.

From web to app

Makromatur started as a web system and was developed as one for a long time. As the project grew, though, it became increasingly clear that the web was a poor fit for what people were actually using the system for. Meal planning, the shopping list and the food diary are things you reach for during the day, often standing in the shop or in the kitchen, and the phone is the device that's always at hand. So I decided to move the whole user experience into a mobile app. The app is written in React Native with Expo and talks to the same Payload backend the website did, so the data model, access control and all the content carried over unchanged. That let me rethink the interface from scratch for phones without starting over on the backend. Along the way the app got a dark interface that fits the mood I wanted far better and makes the product more recognisable.

My role

I have handled all the design, frontend development and backend development of Makromatur. As mentioned before, backend development isn't my main area of expertise, so I had to find a way to build the system such that I could trust the structure and maintain it over the long term. After some searching I discovered the CMS Payload, which solved many of the problems I was facing. The plan was to handle the design and frontend development myself but use Claude Code to help with backend development. I didn't want to trust AI alone with the entire backend build, though. Payload gave the project a clear foundation with, among other things, a built-in user and access system, a well-defined collection structure and thorough documentation. That allowed me to understand for myself how the system worked, review the implementations and make sure Claude Code followed a predefined structure instead of building custom solutions without clear context. This approach let me work faster while keeping better oversight and control over how the backend was built.

What I learned

This is one of the most time-consuming projects I have taken on. The original idea was considerably simpler: to build a platform for recipes and make it easier for users to find, save and use them. After a fair amount of work, however, it became clear that recipes alone probably weren't enough value to build a sustainable business model around the system. For people to see real value in the service, it had to do more than display recipes. It had to help the user through a bigger part of the process, from deciding what to eat to planning the grocery shopping. That's where what you could probably call feature creep began. The project gradually grew as new needs came to light. I added a meal-planning system that can put together a weekly menu, a shopping system that calculates the estimated cost of meals and the week as a whole, as well as comparing where it's cheapest to buy the ingredients. Alongside this it also became necessary to build a separate dashboard for staff. There it has to be possible to monitor what's happening in the system, manage content and users and assist customers, including by checking subscription status and other data related to the service. The project has therefore become much larger and more complex than originally intended. What started as a simple recipe site has evolved into a multifaceted system combining recipes, meal planning, shopping planning, pricing information and operational tools. One of the biggest things I've learned from the project is how hard it is to develop a system this large on your own. When the same person handles ideation, design, frontend, backend, data model, testing and continuous product development, the scope quickly becomes huge. The project has taught me a lot, but also shown me how important good collaboration and clear boundaries are when building a larger digital product.

What would I have done differently?

It took me a long time to find the right final style for the system's design. I went through three or four major redesigns before I finally landed on the direction that felt like a perfect fit for Makromatur, and it wasn't until I moved the product into an app that it truly clicked. Once that design started taking shape, I immediately felt this was the look and identity the project needed. If I had realised earlier that this was always meant to be an app, I would have saved myself a fair amount of work on the web side. If I were to start the project over today, I would also put much more emphasis on planning from the outset. I would have broken the development into clearer phases, defined what should belong to each release and decided earlier which features were essential for the first usable version and which could wait. Fortunately the project is still in active development, so I have the opportunity to improve these practices as it goes on. The aim is for Makromatur to enter closed user testing toward the end of summer 2026, where I'll be able to gather real feedback before the next steps are taken.

Screenshots

Tech