I like building side projects. They’re how I learn new tools, test ideas, and stay sharp outside of work. Over the past year I’ve gone through a few stacks trying to find the right balance between developer experience, cost, and simplicity. I started with Vercel and Supabase. I ended up on Cloudflare and TanStack.

This post is about why.

What I moved away from

Vercel is genuinely excellent for development. The deployment workflow, preview environments, and Next.js integration are top-notch. For a team shipping a product, it makes a lot of sense. But for side projects the free tier is limited, and the moment you need anything beyond it - more bandwidth, analytics, or team features - the Pro plan jumps to $20/month per member. That adds up fast when you’re just experimenting.

Supabase has a similar story. It markets itself as a Firebase alternative with a Postgres database, and it is. But “Postgres under the hood” means you’re still writing SQL for everything - migrations, functions, triggers. The bigger friction is Row Level Security (RLS). In theory it’s elegant: your authorization lives in the database. In practice, writing and debugging RLS policies is painful. Every new table needs policies, every edge case needs another rule, and it slows you down when you’re prototyping.

When you combine the two, the costs stack up. Two paid services, two billing dashboards, and the Supabase free tier doesn’t include automatic backups. For a side project that might sit idle for weeks, that’s hard to justify.

Why Cloudflare ☁️

Cloudflare solves most of what bothered me about the previous stack. Everything runs at the edge - Workers, Pages, KV, D1 - distributed globally without any configuration. Your side project in Warsaw serves just as fast in Tokyo. Instead of stitching together Vercel for hosting and Supabase for the database, you get everything in one place: compute, hosting, database, key-value store, object storage, queues, and cron triggers. One dashboard, one bill.

The free tier is what sealed it for me. Workers get 100,000 requests/day, Pages offers unlimited sites and bandwidth, D1 gives you 5 GB of storage with 5 million reads/day, KV handles 100,000 reads/day, and R2 provides 10 GB with no egress fees. For a side project, you may never leave the free tier. And when you do, the paid plans are cheap.

After years of working with AWS IAM - writing JSON policies, managing roles, trust relationships - Cloudflare’s bindings model feels refreshing. You bind a D1 database or KV namespace to your Worker in wrangler.toml, and it’s available as a variable in your code. No IAM roles, no resource ARNs. Want to add a /api route next to your frontend? It’s the same Worker - just handle the path. No separate Lambda, no API Gateway configuration, no CORS headaches between services. Your frontend and API live together, share the same bindings, and deploy as one unit. The ecosystem backs this up - TanStack Start, Hono, and React Router all deploy to Workers out of the box. When multiple major frameworks invest in your platform, that’s a strong signal.

Why TanStack ⚡

The other half of the equation is the framework. TanStack Start gives you a full-stack React framework with server-side rendering, file-based routing via TanStack Router, and built-in data fetching with TanStack Query. Everything is type-safe end-to-end - from route parameters to API responses. The router catches errors at build time instead of runtime, and Query handles caching, deduplication, and background refetching out of the box.

What matters most for side projects is portability. Unlike Next.js, which is deeply tied to Vercel’s infrastructure, TanStack runs anywhere - Cloudflare Workers, Node.js, Deno, or Bun. If I ever want to move, I can. You don’t want to be locked in to infrastructure you might stop paying for. The developer experience is excellent without the framework trying to own your deployment.

Comparison

How I structure a project

In practice, I run two Cloudflare Workers as a monorepo. The frontend is a TanStack Start worker handling SSR and file-based routing. The backend is a Hono API worker handling auth, database, and business logic. The frontend calls the backend directly through a Cloudflare service binding - no HTTP round-trip, no CORS, just an internal env.API.fetch() call. Both workers share the same cookie prefix, so auth tokens flow seamlessly between them.

For data, D1 handles the relational storage with Drizzle ORM for type-safe queries and migrations. KV stores session data - specifically refresh tokens for the JWT auth flow. R2 is available for file uploads when needed. Everything is bound to the workers through wrangler.toml, so there’s no infrastructure to provision beyond the config file.

This setup deploys as two workers with a single wrangler deploy per workspace. The service binding between them means the frontend-to-backend call stays within Cloudflare’s network - no public endpoint needed for the API.

One small detail worth mentioning: I prefix backend routes with /a/ instead of the conventional /api/. I noticed that /api paths are regularly scanned by bots - automated crawlers probing for exposed endpoints, looking for common frameworks and vulnerabilities. Switching to /a/ reduced random worker invocations to a minimum. It’s a simple change, but it keeps noise out of your logs and your free tier usage low.

Cloudflare’s perception problem

I have a feeling that Cloudflare is not promoted enough as a hosting and application platform. Most developers still think of it as a CDN or a DNS provider. When they hear “Workers,” they picture a backend-only compute layer - something like AWS Lambda, not a place to run a full-stack app. But Workers serve static assets alongside your server code. You deploy one thing and it handles everything.

D1 has a similar perception issue. People hear “SQLite” and immediately associate it with pet projects or local development. SQLite on a single machine - sure. But D1 is SQLite replicated globally across Cloudflare’s network. It handles reads at the edge with automatic replication. That’s not a pet project database - that’s a globally distributed data layer. Yet the “SQLite” label makes people dismiss it before looking at what it actually does.

The result is that Cloudflare has quietly built a serious application platform - Workers, Pages, D1, KV, R2, Queues, Durable Objects - but many developers don’t consider it because the naming and associations don’t match what they expect from “enterprise” or “production-grade” infrastructure.

A note on reliability

Cloudflare has had several notable downtimes in recent months, and that’s worth acknowledging. If your side project grows into something people rely on, a single-vendor dependency becomes a real risk. The good news is that the stack I described is portable by design. TanStack Start can run on AWS Lambda via serverless or on Google Cloud Run with Docker and Bun. Hono has first-class support for both AWS Lambda and Google Cloud Run. Neither framework locks you into Cloudflare’s runtime.

For one of my side projects I’ve started exploring this as an option - setting up a backup for API endpoints on AWS or GCP, so that if Cloudflare becomes unavailable, traffic can fail over to an alternative. It’s a wider architecture problem that touches DNS failover, database replication, and session portability. I might write a dedicated post about it in the future.

Closing thoughts

There’s no perfect stack. Vercel and Supabase are solid products, and for a funded team shipping fast, they might be the right choice. But for side projects - where you want to keep costs near zero, avoid unnecessary complexity, and still build something real - Cloudflare and TanStack hit the sweet spot.

I get global distribution for free, a database that doesn’t require RLS gymnastics, and a framework that doesn’t lock me in. That’s enough to ship ideas without worrying about the bill.

First contract - Pet owners

I am learning blockchain and smart contracts. This post will be my note on how I am starting my journey into blockchain technology.

In this example I will create a contract for storing who is owning a Pet.

Development

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0; //build contract on top of Solidity >=0.8.0 and <0.9.0

contract PetOwner {
    mapping (string => Pet) public petOwners;

    struct Pet {
        string name;
        string petType;
    }

    function addPetOwner(string memory ownerName, string memory _name, string memory _petType) public {
        petOwners[ownerName] = Pet({name: _name, petType: _petType});
    }

}

Put it in the Remix IDE: https://remix.ethereum.org/. It should compile and we can deploy it on the local environment:

When we have contract deployed we can create example contract ownership

and ask petOwners field for information which Pet is owned by Marcin.

Let’s deploy it to Ethereum test network

Ethereum allows testing our contract on test networks. For this example I will use Rinkeby. This is a free network for testing smart contracts.

I am not covering how to install Metamask. Always remember to not share private key and seed You can always create a new Metamask identity for your tests.

1. Switch the Remix Environment from Javascript VM to Injected Web3
2. Connect your Metamask. Ensure you have chosen Rinkeby network
3. If you don’t have any ETH coins you can use this Faucet to grab some: https://faucets.chain.link/rinkeby
4. Click deploy. You will be asked by Metamask to confirm the transaction: Contract deployment transaction

Now I can test my contract. I fill the data

And we will be asked again for confirming the transaction .

When everything will be done, our transaction should be visible on Etherscan

And at the end we can check if petOwner field contains our definition:

This post contains my notes from a Blockchain development tutorial available here.

Updated on 24-02-2026: Improved the script to use getHeader() instead of raw body search, added data-driven header configuration, and auto-creation of labels.

📨 How GitLab sends notifications?

GitLab allows you to stay informed about what’s happening in your projects sending you the notifications via email. With enabled notifications, you can receive updates about activity in issues, merge requests or build results. All of those emails are sent from a single address which without a doubt makes it harder to do successful filtering and labeling.

However GitLab adds custom headers to every sent notification to allow you to better manage received notification and for example, you could add a label to all emails with pipelines results to mark them as important. Similarly, you could make the same scenario for notification about the issue assigned to you. Some of the headers that you can find in emails are:

As can be seen above headers allow you to create example condition: if the email contains the header X-GitLab-Issue-ID then add a label “GitLab Issue”.

Of course, there are more headers available. The full list of headers, which GitLab can include to emails is available in the section “Filtering email” of GitLab documentation. Every header also contains a value. Some headers contain an ID, some contain names of projects. You can check out them in the documentation.

📥 How to filter emails in Gmail by header?

To automatically add labels in Gmail you have to create a filter. However, it does not allow to filter by headers. But this is not impossible.

Google provides a special service called Google Apps Scripts. It allows you to write short scripts in JavaScript, where you can extend default Gmail filtering.

⌨️ How can I add a label to message by headers?

Firstly you have to begin with function, which will be scheduled to query for new emails in the inbox and will execute further message processing:

function processInbox() {
   // process all recent threads in the Inbox
   var threads = GmailApp.search("in:inbox from:gitlab@* newer_than:1h");
   for (var i = 0; i < threads.length; i++) {
      // get all messages in a given thread
      var messages = threads[i].getMessages();
      for (var j = 0; j < messages.length; j++) {
         var message = messages[j];
         processMessage(message); // function to process the message
      }
   }
}

As you see, the code is pretty simple. It uses search() function from GmailApp which allows you to interact with Gmail service. The search query "in:inbox from:gitlab@* newer_than:1h" filters only GitLab emails from the last hour. After that we have to get the message content. We can do it by writing a loop to get every message from a thread. The getMessages() function returns a list of Gmail Messages objects. Having them we can implement our actions based on the content.

To do that you can use the getHeader() function on the message object to read a specific email header by name. For example, to check the pipeline status:

var status = message.getHeader("X-GitLab-Pipeline-Status");
if (status) {
  // header exists - this is a pipeline notification
}

This is more reliable than searching the raw email body for header names, which could produce false positives if the header name appears in the message text.

To make the script easy to extend, we can define a configuration map that describes which headers to look for and what labels to apply. The full script looks like this:

// Label to apply on any GitLab match
var mainLabel = "GitLab";

// Configuration: header → label mapping
// nestValue: true  → creates sub-label with the header value, e.g. Pipeline/failed
// matchValue: "x"  → only applies the label when the header value equals "x"
var headersMap = {
  "X-GitLab-Pipeline-Status":      { "label_name": "Pipeline",   "nestValue": true },
  "X-GitLab-Project":              { "label_name": "Project",    "nestValue": true },
  "X-GitLab-NotificationReason":   { "label_name": "Reason",     "nestValue": true },
  "X-GitLab-Issue-ID":             { "label_name": "Issue" },
  "X-GitLab-MergeRequest-ID":      { "label_name": "MergeRequest" },
  "X-GitLab-Discussion-ID":        { "label_name": "Discussion" },
  "X-GitLab-MergeRequest-State":   { "label_name": "Merged",     "matchValue": "merged" },
};

function processInbox() {
  var threads = GmailApp.search("in:inbox from:gitlab@* newer_than:1h");
  for (var i = 0; i < threads.length; i++) {
    var messages = threads[i].getMessages();
    for (var j = 0; j < messages.length; j++) {
      processMessage(messages[j]);
    }
  }
}

function processMessage(message) {
  var firstMatch = true;
  for (var header in headersMap) {
    var val = message.getHeader(header);
    if (val) {
      if (firstMatch) {
        firstMatch = false;
        addOrCreateLabel(mainLabel, message);
      }
      var labelText = headersMap[header]["label_name"];
      if (headersMap[header]["matchValue"]) {
        if (val != headersMap[header]["matchValue"]) continue;
      } else if (headersMap[header]["nestValue"]) {
        labelText += "/" + val;
      }
      addOrCreateLabel(labelText, message);
    }
  }
}

function addOrCreateLabel(labelText, message) {
  var label = GmailApp.getUserLabelByName(labelText);
  if (!label) {
    label = GmailApp.createLabel(labelText);
  }
  message.getThread().addLabel(label);
}

The headersMap at the top is the only thing you need to edit to add new labels - no code changes required. Labels are created automatically if they don’t exist yet.

▶️ How to turn on the script processing for you Gmail inbox?

1. Go to Google Apps Scripts.

2. Create a new project, put your code and save.

3. From the Web IDE you can perform the execution to check for errors. Select function processInbox and click Play button:

4. You will be asked to permit a project access to your Gmail data. Choose your account:

5. After successful authorization, you can re-run the project. It will be immediately executed.

6. When there is no errors, create a custom trigger. Find button:

7. Click “Add trigger” button at the bottom of the page.

8. Select function processInbox and configure the time source. The execution frequency is your choice. If you receive a lot of messages and you will run this script every 1 minute you can hit the limits. In the above script, I am scanning for emails from the last hour so the script can be executed at least once an hour.

🏁And that’s it!

Google should now start executing your script and checking for new emails to make actions which you just implemented. The result of running this script is to label new emails from GitLab as you want 🤗.

📖 Summarize

Gmail filters are sufficient for most users’ needs. However, if your use case is more advanced, Google Apps Scripts comes to the rescue. It doesn’t require deep programming knowledge and by searching online you can solve your problems. Remember that you can have multiple scripts to process your inbox.

Did you know about Google App Scripts before? Please share how are you using them in the comments below.