Part 4 of my guide to building custom tools with Ai.

Cooking or catering?

Tuesday, 26 August, 2025

Let’s rewind a bit. Once you draft your first app with ai, you face a crucial decision: where should it live, where should it be built? Think of it as choosing between cooking your own food or hiring a catering service. Both get you fed, but the choice shapes your entire relationship with your creation.

Cooking or catering?

No matter if you were a designer in 1999, 2010, or today. You have always been armed with Photoshop, Balsamiq, Sketch, Invision or Figma. Season that with user research, and the latest design system. You are perfectly set to craft the perfect ux and interface – clean, usable, delightful. You present it to the development team with pride.

Then comes the inevitable response: «This looks great, but we can’t actually build it with our current infrastructure.» … Sound familiar?

Welcome to the gap between what we design and what can be built.

The 99% problem

Most designers today spend 99% of their time on user needs and user behavior. Don’t get me wrong, understanding users is über-crucial. But here’s what we’re missing: a chunk of your time should be focused on learning the infrastructure you’re working with.

Think about it like this: if you design the perfect interface but the backend can’t deliver it, you’ve achieved precisely nothing.

Why third-party solutions won’t save you

«But can’t I just use Webflow, Bubble, Base 44, Lovable, Framer, or [insert no-code tool of your choise here] and skip all this infrastructure nonsense?»

Sure, you can. But you’ll end up doing exactly what we did when we moved from Photoshop to Sketch to Figma – transferring old behaviors into new tools without understanding what happens behind the curtain.

These platforms are brilliant for prototyping and getting started, but they’re also like catering your food: black boxes where you pick and choose and become nowhere better at cooking. You’re still manipulating interfaces without understanding the pipes, the databases, the salts, the peppers, and the inner workings that gives an app its flavour and taste.

The 50-75-100% strategy

Instead of aiming for the perfect interface from day one, start with this approach:

50% infrastructure-aware design: Build interfaces that work as good as possible for your users needs and your current technical constraints. Maybe it’s not the dream ux or interface, but it’s something that can actually be built and deployed quickly.

Move to 75%: Identify what improvements would get you to a better user experience. Maybe it’s a backend change, a new api, perhaps better research or user testing.

Finish at 100%: Keep the perfect interface in mind as your north star, but understand the technical journey required to get there.

I believe that if you go straight for 100% from day one, you’ll spend so much time and energy fighting for your solution that when you’re finally finished, you’ll have alienated team-members, coworkers, project managers, and perhaps even clients. You become the «100% troll» – nothing less than perfect is good enough and you will be impossible to work with.

But if you take the 50-75-100% approach, you’ll spend the same total amount of energy. The difference? During that journey from 50 to 100%, you’ll gain understanding, spread knowledge, and onboard coworkers on ux and design thinking. Developers will start understanding what you actually want. You’ll build a much better team culture and collaboration because you’re demonstrating that you’re willing to lower the barrier, ready to collaborate and iterate together with your team.

Damn, I bet your finished solution will be even better than the one you aimed for in the 100%-from-day-1 approach.

This isn’t settling for mediocrity – it’s being smart about the relationship between design and implementation, and even smarter about human relationships.

The infrastructure-aware designer

I’ve said it before: start buiding your own apps! Once you understand the pipes behind the interface, something magical happens:

You design better interfaces. Because you know what’s technically feasible, you can push the boundaries in ways that actually work.

You communicate better with developers. Instead of «make this!» you can have informed conversations about tradeoffs, priorities and user experience.

You become more valuable. Designers who understand infrastructure are rare and incredibly valuable to any team.

You build better products. When you understand both user need and technical constraints, you find creative solutions that satisfy both.

The Future’s So Bright, I Gotta Wear Shades

As a designer who’s spent 20 years watching the industry evolve, I can tell you with absolute certainty:

Designers who understand technology have a massive competitive advantage.

We’re living in an, to me, absolutely incredible time. The barrier between «I have an idea» and «I have a working app» has never been lower. When you self-host, you’re not just building apps – you’re building technical literacy. You start understanding how data flows, how servers think, how users actually interact with your creations. This knowledge bleeds into everything else you design.

The designer who can say “I build custom app to solve problems” isn’t just someone who can push pixels around. They’re a designer who understands the full recipe of digital creation.

Jomenvisst, såäre. Å de e jävligt schysst!.


Next up: How I replaced WeTransfer with custom image banks for my clients.