DEV Community: Martin Eley

Creating a takeout food order agent using Supabase and n8n - Part 1

Martin Eley — Thu, 16 Apr 2026 16:12:02 +0000

Prerequisites: to follow along you will need:

Mermaid Account
Docker installed locally
Supabase installed locally
Visual Studio Code (or IDE of your choice)
Mermaid Extension for Visual Studio Code
Claude Code

Now I love curry but I have a problem, every time I order takeout I promise myself I’m going to try something new, but then I end up ordering the same thing I always order. There’s a whole world of asian cuisine I am missing out on. I think it would be really nice if the restaurant I order from had some way of making a recommendation like a waiter in a restaurant.

In this series of blog posts I am going to walk you through the steps to create a takeout agent using Supabase and n8n. Throughout this series you will learn how these two platforms do a lot of the heavy lifting for us, helping us create our agent in as little time as possible without compromising things like security. Let’s get started!

Like most dev pipelines, we’re going to start by developing locally before deploying, in the last post in this series we will cover the steps to deploy your application.

Database Design

First of all I want us to think about the design of our database. A little time spent here will save us lots of time later on. I like to use Mermaid Diagrams for planning my database design. Mermaid uses markdown definitions to create diagrams which can then be downloaded to your local machine and checked into source control.

Here you can see my Mermaid Diagram for our takeout restaurant. This is a simplified e-commerce model, we have five tables for storing details about customers, their basket, order, order items and products. The customer table has a foreign key on the primary key, this is because the unique id for the customer will also refer to the user id in Supabase, more about this later. You will also notice we have a basket table. This acts as a temporary holding area, making it easier for the agent to manage items without having to navigate multiple tables, you will learn more about this in part two.

Initialise Supabase

The first thing we need to do is initialise our Supabase project. If you don’t have Supabase and Docker installed locally go ahead and do that first, instructions are here.

Once installed use these commands to initialise and start your project

$ cd ~
$ mkdir takeout
$ cd takeout
$ supabase init
$ supabase start

Now we have Supabase running locally we can start to create our database.

Create database schema

The nice thing about using Mermaid diagrams is we can sync them with Visual Studio Code using the Mermaid Extension.

Install the Extension, log in to your Mermaid account then select which diagram to use. This will create a local version of your diagram which we can use to create our schema in Supabase.

You can use my Entity Relationship Diagram here.

Here you can see we now have the ERD saved locally, and any changes we make will be sync’d with the version in the cloud.

This is where it gets interesting, we could generate Supabase migrations manually by entering the relevant SQL statements to create each individual table but instead, we’re going to save some time and use Claude AI to do this for us.

To do this you will need to sign up to Claude and install the Visual Studio Code Extension.

Once you have completed these steps open up Claude in Visual Studio, log in and use the following command to initialise Claude for our project:

/init

This will create a CLAUDE.md file for us, this is an important file as it provides persistent instructions for Claude. In our case it tells Claude that this is a Supabase project, adding necessary context. Next we should tell Claude to enable Plan Mode. This means it won’t actually make any file changes, it will just show us the plan. This is important, because LLMs can hallucinate so we want to review the proposal before making any changes, especially when we’re asking a LLM to write row level security policies for us.

/plan

So now we can ask Claude to generate our database migrations for us by using this prompt:

> using @file:[YOUR ERD].mmd generate Supabase migrations for each entity.  The customer entity has a primary key customer_id that is also a foreign key that references Supabase auth.users(id).  Generate row level security rules as follows: product is public read. customer can be read, created and updated  by authenticated user. basket can be read, created, updated and deleted by authenticated user. order can be read, created and updated by authenticated user, order_line_item can be read, created and updated by authenticated user.

There is a very important reason why we ask Claude to plan our migrations first. In our prompt you can see we’re asking Claude to write row level security policies for us. We all know LLMs are prone to errors and hallucinations and there’s a real risk we could introduce a silent but dangerous vulnerability into our application! This way we act as the human in the middle, we check the code before it gets executed and therefore, we have an opportunity to catch errors and stop them making their way into our code.

After checking the plan, once you’re happy with the output you can tell Claude to proceed and generate the migrations for you. Next you need to run those migrations, use this command:

supabase db reset

Now if you navigate to http://localhost:54323/ and click Database you should see something like this:

So now we have our database schema set up, but we have no data in the Products table, let’s sort that out by creating a seed. As before we will use Claude to do this for us:

> In this project there is a table called products, seed this table with typical menu items from an indian takeout.

Like before use this command to apply our changes to Supabase.

supabase db reset

Now we have our database populated with some products, but we have much more than that, Supabase also gives us an entire application backend. In the next post we will be using Supabase REST API and authentication all of which are provided for us already, pretty neat right?

In the next post I will show you how to create the agent using n8n, connect it to our Supabase database and embed it in a website.

If you want to check out the code from this post you can find it here: https://github.com/steamhammercouk/takeout

Your DevOps Pipeline Is Not a Strategy

Martin Eley — Tue, 31 Mar 2026 16:30:34 +0000

Build or Buy? This is the question every CTO has to face at some point. Do you opt to use IaaS or PaaS, do you opt to build your own pipeline or buy an off the shelf platform? Most CTOs will pick a lane and go all in, but I think that’s a mistake and a missed opportunity.

There are risks and tradeoffs involved when you choose a single lane and the smart CTOs know it. Think of it like this, you’re not a CTO but the head engineer of a race team. Do you choose to focus all of your attention on just the engine? Of course not, you tune the whole car, working on the engine, the steering and the suspension.

Now imagine you’re tuning your architecture, the smart CTOs are focusing on every layer available to them, not just going all in on IaaS.

As a CTO you have access to a lot of tools spread across the three different layers of architecture, SaaS, PaaS and IaaS. It’s important to remember, these layers aren’t competitors, they’re complementary, the goal isn’t to choose the right layer, it’s to know when to use the right one.

SaaS, this is the layer that provides you with commodity capabilities, the things that everyone does, HR, ERP, CRM, etc. There’s not much opportunity to differentiate in this layer, but it can deliver efficiencies that help become a cost leader. Don’t build what you can buy, save your budget for differentiation.

PaaS, these are the platforms that allow you to start to create the things that make your organisation unique and help you differentiate. These platforms do the heavy lifting for you by providing an opinionated, repeatable way of doing things. They let your developers focus on creating value without having to reinvent the wheel. PaaS is great for rapidly building prototypes, MVPs, or projects where you need to prove value fast.

IaaS, this is the layer you use when control matters most if you’re building something unique, have a complex problem, high volumes of data or need massive global scale. This is the layer that gives you maximum control but maximum responsibility. However, complexity and control have a cost overhead.

I have seen over many years CTOs who have chosen to go all-in on a hyperscaler. Organisations start off with a clean pipeline but over time it becomes a sprawling mess, with complex network configuration, virtual machines, build processes and YAML files that confuse developers.

At the start CTOs may look at PaaS pricing as a premium tax they’re not willing to pay. CTOs will choose the DIY path because it gives them more control over components, leading to a belief that decoupling makes cost control easier when compared to a PaaS.

However, those choosing to build their own pipelines over time, unknowingly accrue a DIY tax. The complexity eventually starts to creep and so does the cost, in money and headcount, with DevOps teams growing steadily. Organisations risk hitting a point where the benefits of building your own DevOps pipeline are outweighed by complexity and cost, that start to slow down the rate of delivery and stall innovation, and at the same time your competitors start to ship faster than you.

To overcome the risk of over engineering in a single layer you need to think more like an Enterprise Architect and assess each layer on its own merits, it’s all about using the right tool, for the right job, at the right time. Enterprise Architects don’t think like engineers, they think about what’s right for the organisation at that point in time, for them it’s not about choosing a layer, it’s about aligning technology with strategy, goals and value to ensure the organisation is more likely to get value from their IT investments.

A handy framework for deciding which layer to use involves thinking like an Enterprise Architect without the need to become one. When choosing a layer ask yourself:

How well does this align with my organisation’s goals and objectives? Does this create value, an advantage or is it just infrastructure for the sake of it?
Do we know the total cost of what we’re about to take on? Does the additional expense make this a sensible decision or does it erode value?
Apply the 80/20 rule, can this get me 80% of the way there with 20% of the effort? Or, inversely, does 80% of the effort only solve 20% of the problem?
Can I achieve something by spreading myself across multiple layers, can I get the best by combining no/low code SaaS, with speedy PaaS and dip into IaaS when I really need to?

The best CTOs choose not to invest in a single layer, they’re picking the right tool for the job and keep revisiting those decisions as the organisation changes and grows. That’s the key point to remember, going all-in on a single layer early on reduces agility in the long run, it’s better to spread your bets, use the best of what’s on offer and go deep when it makes sense. Don’t forget a well-tuned car performs better than one with a monster engine, the same applies to your architecture.