Forem: Esin Saribudak

Build your own blog post view counter on AWS Free Tier

Esin Saribudak — Tue, 21 Apr 2026 19:35:19 +0000

Your blog deserves to know it's being read. A Lambda function counts the views, DynamoDB remembers them, and it's all eligible for the Free Tier.

Last updated: April 20, 2026

Most analytics tools require an account, a script tag, and a separate dashboard you have to check outside your infrastructure. If you're already on AWS, you can build a view counter that lives in your own account and stores data in a table you control. It takes about an hour, and all three services it uses are eligible for the AWS Free Tier.

This tutorial walks you through building that counter. You add one <script> tag to your blog, and every time someone reads a post, the count goes up in a DynamoDB table you own.

Along the way, you'll wire together Lambda, DynamoDB, and API Gateway into something that goes beyond "Hello World." By the end, you'll have working software on your blog and hands-on experience with the same services that power production applications.

If you've already set up your AWS account and deployed something to the cloud before, this is a good next project. If you haven't, start with a free AWS account and come back.

What you're building

Here's the application flow:

A visitor loads your blog post in a browser
A small script on your page sends a request to API Gateway
API Gateway invokes a Lambda function
Lambda checks DynamoDB to see if this visitor has already been counted today
If they're new, it increments the counter
API Gateway returns a 204 response to the client

Two serverless services for compute and storage, one API layer in front, about 100 lines of TypeScript.

The counter deduplicates by IP address (hashed, so you're not storing raw IPs) and auto-cleans old records with DynamoDB's TTL feature. You add it to your blog with a single <script> tag, and it automatically tracks every page.

Prerequisites

An AWS account. If you don't have one yet, the Creating an AWS account guide walks you through it. You'll need a credit card on file, but this project stays within Free Tier limits.
Node.js 24 or later
AWS CLI installed and configured. Follow the AWS CLI quickstart if this is your first time.
AWS CDK bootstrapped in your account:

npx cdk bootstrap aws://YOUR_ACCOUNT_ID/us-east-1

If you haven't used CDK before, it's an AWS infrastructure-as-code tool. You write TypeScript that describes your AWS resources, and CDK turns it into CloudFormation and deploys it. The bootstrap command creates a staging bucket CDK needs to upload your code. The CDK getting started guide has more information if you want it.

Project setup

Create a new directory and initialize the project:

mkdir blog-post-view-counter && cd blog-post-view-counter
npm init -y
npm install aws-cdk-lib constructs @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb
npm install -D aws-cdk tsx typescript @types/node

Create a cdk.json file in the project root. This tells CDK how to run your app:

{
  "app": "npx tsx cdk/app.ts"
}

And a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "lib": ["ES2022"],
    "outDir": "dist",
    "rootDir": ".",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true
  },
  "include": ["lambda/**/*", "cdk/**/*"]
}

Your project structure will look like this:

blog-post-view-counter/
├── cdk/
│   ├── app.ts          # CDK entry point
│   └── stack.ts        # Infrastructure definition
├── lambda/
│   └── index.ts        # Lambda function code
├── cdk.json
├── package.json
└── tsconfig.json

Step 1: The DynamoDB table

DynamoDB is a key-value database. You give it a key, it gives you back the data. No servers to manage, no connection strings to configure.

Our table stores two kinds of records using a composite key (pk + sk):

Counter records track views per page:

pk	sk	views
`/blog/my-first-post`	`counter`	42
`/about`	`counter`	17

Dedup records prevent the same person from being counted twice:

pk	sk	ttl
`/blog/my-first-post#a1b2c3d4...`	`dedup`	1745208000

The dedup key combines the page path with a hash of the visitor's IP. The ttl field is a Unix timestamp 24 hours in the future. DynamoDB automatically deletes expired records, so the same visitor gets counted again the next day.

Think of it like a filing cabinet. Each drawer is labeled with a page path. Inside, there's a counter folder with the view count, and temporary visitor sign-in sheets that get shredded after 24 hours.

Step 2: The Lambda function

Create lambda/index.ts. This is the code that runs every time someone visits your blog:

import { createHash } from 'node:crypto';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand, PutCommand, UpdateCommand } from '@aws-sdk/lib-dynamodb';

// DynamoDB document client — lets us read/write JS objects instead of raw DynamoDB types
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE_NAME = process.env.TABLE_NAME!;
const DEDUP_HOURS = 24;

// These come from environment variables set in the CDK stack
const ALLOWED_ORIGIN = process.env.ALLOWED_ORIGIN || '*';
const ALLOWED_HOSTNAME = ALLOWED_ORIGIN !== '*' ? new URL(ALLOWED_ORIGIN).hostname : null;

// CORS headers — browsers require these when your blog (yourdomain.com)
// makes a fetch() to a different domain (your API Gateway URL)
const CORS_HEADERS = {
  'Access-Control-Allow-Origin': ALLOWED_ORIGIN,
  'Access-Control-Allow-Methods': 'GET,OPTIONS',
  'Access-Control-Allow-Headers': 'Content-Type',
};

// Only allow typical blog URL paths — letters, numbers, hyphens, slashes, dots
const VALID_PATH = /^\/[\w\-./]{0,199}$/;

// Hash an IP so we never store raw addresses in DynamoDB (GDPR-friendly)
function hashIp(ip: string): string {
  return createHash('sha256').update(ip).digest('hex').slice(0, 16);
}

export const handler = async (event: any) => {
  // Handle CORS preflight — browsers send this before the real request
  if (event.httpMethod === 'OPTIONS') {
    return { statusCode: 204, headers: CORS_HEADERS, body: '' };
  }

  const page = event.queryStringParameters?.page || '/';

  // Reject paths that don't look like blog URLs
  if (!VALID_PATH.test(page)) {
    return { statusCode: 400, headers: CORS_HEADERS, body: '' };
  }

  // If a Referer header exists, make sure it's from your site
  if (ALLOWED_HOSTNAME) {
    const referer = event.headers?.referer || event.headers?.Referer || '';
    if (referer && !referer.includes(ALLOWED_HOSTNAME)) {
      return { statusCode: 403, headers: CORS_HEADERS, body: '' };
    }
  }

  // Combine page path + hashed IP to create a unique dedup key
  const ip = event.requestContext?.identity?.sourceIp || 'unknown';
  const dedupKey = `${page}#${hashIp(ip)}`;
  const now = Math.floor(Date.now() / 1000);
  const ttl = now + DEDUP_HOURS * 3600; // DynamoDB TTL auto-deletes after 24h

  // Check if this visitor was already counted for this page today
  let isNewView = true;
  try {
    const existing = await client.send(new GetCommand({
      TableName: TABLE_NAME,
      Key: { pk: dedupKey, sk: 'dedup' },
    }));
    if (existing.Item) isNewView = false;
  } catch {
    // If lookup fails, count it as a new view
  }

  if (isNewView) {
    // Write a dedup record so this IP won't be counted again for 24h
    await client.send(new PutCommand({
      TableName: TABLE_NAME,
      Item: { pk: dedupKey, sk: 'dedup', ttl },
    }));

    // Increment the page's view counter (ADD creates the item if it doesn't exist)
    await client.send(new UpdateCommand({
      TableName: TABLE_NAME,
      Key: { pk: page, sk: 'counter' },
      UpdateExpression: 'ADD #v :inc',
      ExpressionAttributeNames: { '#v': 'views' },
      ExpressionAttributeValues: { ':inc': 1 },
    }));
  }

  // 204 No Content — the browser doesn't need a response body
  return { statusCode: 204, headers: CORS_HEADERS, body: '' };
};

The code comments cover the details, but here's the high-level flow: the function validates the incoming page path, checks the Referer header, then hashes the visitor's IP with SHA-256 so no raw addresses end up in your database. It looks up the hashed IP in DynamoDB to see if this visitor was already counted today. If not, it writes a dedup record (which DynamoDB auto-deletes after 24 hours via TTL) and atomically increments the page's view counter. The browser gets back a 204 No Content, meaning "got it, nothing to show you."

Step 3: The infrastructure

Create cdk/stack.ts. This defines all three AWS resources:

import * as cdk from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
import { fileURLToPath } from 'url';
import { Construct } from 'constructs';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

export class ViewCounterStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // Read your blog's domain from the deploy command:
    //   npx cdk deploy -c blogOrigin=https://yourdomain.com
    const blogOrigin = this.node.tryGetContext('blogOrigin');
    if (!blogOrigin) {
      throw new Error('Missing required context: -c blogOrigin=https://yourdomain.com');
    }

    // DynamoDB table — stores page view counts and IP dedup records
    const table = new dynamodb.Table(this, 'ViewCounterTable', {
      partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
      sortKey: { name: 'sk', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PROVISIONED,
      readCapacity: 25,  // 25 RCU is within the always-free tier
      writeCapacity: 25, // 25 WCU is within the always-free tier
      timeToLiveAttribute: 'ttl', // Auto-delete dedup records after 24h
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Clean up on `cdk destroy`
    });

    // Lambda function — NodejsFunction bundles TypeScript with esbuild automatically
    const fn = new NodejsFunction(this, 'CounterFunction', {
      runtime: Runtime.NODEJS_24_X,
      entry: path.join(__dirname, '../lambda/index.ts'),
      handler: 'handler',
      environment: {
        TABLE_NAME: table.tableName,
        ALLOWED_ORIGIN: blogOrigin, // Passed to Lambda for CORS and Referer checks
      },
      timeout: cdk.Duration.seconds(10),
      memorySize: 128,
    });

    // Give the Lambda read/write access to the DynamoDB table
    table.grantReadWriteData(fn);

    // API Gateway — public HTTPS endpoint that triggers the Lambda
    const api = new apigateway.RestApi(this, 'CounterApi', {
      restApiName: 'blog-post-view-counter',
      deployOptions: {
        throttlingRateLimit: 10,   // Max 10 requests/second sustained
        throttlingBurstLimit: 20,  // Allow short bursts up to 20/second
      },
    });

    const integration = new apigateway.LambdaIntegration(fn);

    // CORS — only allow requests from your blog domain
    const corsOptions: apigateway.CorsOptions = {
      allowOrigins: [blogOrigin],
      allowMethods: ['GET', 'OPTIONS'],
    };

    // GET /counter?page=/some-path — record a page view
    const counter = api.root.addResource('counter');
    counter.addMethod('GET', integration);
    counter.addCorsPreflight(corsOptions);

    // Print the tracking URL after deploy
    new cdk.CfnOutput(this, 'CounterUrl', {
      value: `${api.url}counter`,
      description: 'Tracking endpoint',
    });
  }
}

A few things to notice:

NodejsFunction instead of Function. You're writing TypeScript, but Lambda runs JavaScript. The regular lambda.Function construct would deploy your .ts files as-is, and Lambda wouldn't know what to do with them. NodejsFunction compiles your TypeScript to JavaScript with esbuild at deploy time. You write TypeScript, Lambda gets JavaScript, and you don't need a separate build step.
Provisioned capacity at 25/25. DynamoDB's always-free tier gives you 25 read capacity units and 25 write capacity units at no cost. That's 25 reads and 25 writes per second, which is way more than a personal blog needs. We're using provisioned mode instead of on-demand specifically to stay within this free allocation.
removalPolicy: DESTROY. By default, CDK protects your DynamoDB table from accidental deletion. Since this is a learning project, we set it to DESTROY so cdk destroy cleans everything up. For a production table, you'd leave the default.
Throttling. API Gateway is set to 10 requests per second with bursts up to 20. This caps how much traffic can hit your Lambda and DynamoDB, which limits your bill if someone discovers your endpoint and tries to hammer it.

Now create the CDK entry point at cdk/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { ViewCounterStack } from './stack.js';

const app = new cdk.App();
new ViewCounterStack(app, 'BlogPostViewCounterSampleForAws');

Step 4: Deploy

One command:

npx cdk deploy -c blogOrigin=https://yourdomain.com

Replace yourdomain.com with your actual blog domain. CDK will show you a summary of the resources it's about to create and ask for confirmation. Type y.

After about a minute, you'll see output that looks something like this:

Pay special attention to the Outputs section with the CounterUrl endpoint.

Outputs:
BlogPostViewCounterSampleForAws.CounterUrl = https://abc123.execute-api.us-east-1.amazonaws.com/prod/counter

That's your tracking endpoint. Save that URL.

Step 5: Add it to your blog

Add this script tag to your site's base layout. In Astro, that's your layout component. In Hugo, it's baseof.html. In plain HTML, put it before the closing </body> tag.

<script>
  fetch(`https://YOUR_COUNTER_URL?page=${encodeURIComponent(window.location.pathname)}`);
</script>

Replace YOUR_COUNTER_URL with the URL from the deploy output.

Here's what it looks like in an Astro blog layout, with the real endpoint URL:

<BaseLayout {title} {description} {image} type="article" {pubDate}>
  <script type="application/ld+json" set:html={JSON.stringify(schemaData)} slot="head" />

  <script>
    fetch(`https://u1sdf1bq66.execute-api.us-east-1.amazonaws.com/prod/counter?page=${encodeURIComponent(window.location.pathname)}`);
  </script>

  <a href="/blog" class="back-link">&larr; all posts</a>

  <article>
    <header class="post-header">
      <h1 class="post-header__title">{title}</h1>
      <p class="post-header__meta">
        <time datetime={pubDate.toISOString()}>{formattedDate}</time>
        {formattedUpdated && (
          <span> &middot; updated {formattedUpdated}</span>
        )}
      </p>
    </header>

    <div class="post-body">
      <slot />
    </div>
  </article>
</BaseLayout>

Now every page load fires a request to your API, which counts the view and returns a 204. The window.location.pathname part means it automatically sends the current page's path, so you don't need to configure anything per post.

Step 6: Check your view counts

Open the DynamoDB console, find your table, and click "Explore table items." If you have a lot of items, filter for items where sk equals counter. You'll see each page path and its view count.

You can also run this from the CLI:

aws dynamodb scan \
  --table-name YOUR_TABLE_NAME \
  --filter-expression "sk = :sk" \
  --expression-attribute-values '{":sk": {"S": "counter"}}'

How much does this cost?

This project uses services eligible for the AWS Free Tier. Depending on your usage and account status, charges may apply. Here's the breakdown:

DynamoDB provisioned at 25 WCU/25 RCU is within the always-free tier. No cost regardless of account age.
Lambda gives you 1 million requests per month free. Most personal blogs will stay within these limits.
API Gateway is the only service with a direct cost: $3.50 per million requests for REST APIs in us-east-1. A blog getting 10,000 views per month would cost about $0.035, which comes out of your Free Tier credits if you're a new customer.

I'd recommend setting up a billing alarm at $5 as a best practice in new sandbox accounts.

What you just learned

If you followed along, you now have hands-on experience with:

DynamoDB: composite keys, TTL for automatic cleanup, atomic counters with UpdateExpression
Lambda: handling HTTP events, environment variables, working with the AWS SDK
API Gateway: REST endpoints, CORS configuration, throttling
CDK: defining infrastructure in TypeScript, deploying with a single command

And you have something running on your blog that you built from scratch.

Cleanup

If you want to tear everything down:

npx cdk destroy -c blogOrigin=https://yourdomain.com

This deletes the Lambda, the DynamoDB table, and the API Gateway endpoint. All your view count data will be gone, so make sure you're done with it.

What to try next

Add a billing alarm so you get an email if your AWS charges go above $5
Build a small dashboard that reads from DynamoDB and displays your view counts
Track views over time by adding a date field to the counter records

The source code for this project is on GitHub if you want to fork it and make it your own. Let me know in the comments what you're building this week!

How I trained a computer vision model on the AWS Free Tier

Esin Saribudak — Fri, 27 Mar 2026 01:20:43 +0000

Last updated: March 26, 2026

Developers hide Easter eggs in code. Filmmakers hide them in scenes. I hid them in AI-generated images and asked Amazon Rekognition to find them.

If you've ever wondered whether AWS Free Tier gives you enough credits to build something cool, this post is for you. I built an Easter egg detector powered by Amazon Rekognition, tested its standard object detection API on 37 images, and trained a custom model, all with my AWS Free Tier credits.

(If you haven't set up a Free Tier account, check out this great guide!)

The idea

I wanted to build a simple and fun app where I can upload a photo and have the app tell me if there's an Easter egg in it. It sounds kind of silly, but the technical problem it maps to — locating a small, specific object in a complex scene — is a foundational one for the field of computer vision.

AWS has a lot of services for different AI/ML use cases, including Amazon Rekognition for computer vision. I learned that organizations like C-SPAN and the NFL use it to understand what's in their images and video. And Amazon Rekognition is available on the AWS Free Tier, which makes experimenting with it easier.

The service gives you different ways to figure out what's in images. The DetectLabels API works out of the box and recognizes thousands of common objects and concepts, everything from aircraft to zucchini to birthday parties. Custom Labels let you train your own computer vision model when the built-in labels fall short. With this project, I wanted to find out where the first one stops being useful and the other is needed.

What I built

The app I built to explore that question is a Streamlit app with two modes. Standard mode sends your image to the DetectLabels API and checks if it returns "Egg" or "Easter Egg" in the labels. Custom Labels mode uses a custom model I trained on my own images. Both draw bounding boxes around any eggs they find.

The application code is about 200 lines of Python, 100 lines of which is UI-related, and you can check it out at this GitHub repo. You upload an image, the app calls Rekognition using the AWS SDK for Python (Boto3), checks the response, and draws some boxes around any eggs that it finds.

Here’s an example of code that handles regular DetectLabels requests.

response = rekognition.detect_labels(
    Image={"Bytes": image_bytes},
    MaxLabels=30,
    MinConfidence=30.0,
)

Generating test images

I needed images with scenes where Easter eggs would be unexpected. I used an image generator to create 19 images: a messy desk with an egg tucked next to the monitor, a toy box with a painted Easter egg between two teddy bears, a picnic spread with a couple eggs in between the sandwiches.

Then I generated 18 images with no eggs at all, but similar to the other scenes. That gave me a relatively balanced dataset to start with.

Round 1: DetectLabels

I wrote a batch test script (also in the GitHub repo) that ran every image I had through DetectLabels and checked whether Rekognition found an egg.

The results at a 30% confidence threshold:

Metric	Score
Accuracy	75.70%
Precision	100%
Recall	52.60%

100% precision means it never hallucinated an egg where there wasn't one in the no-egg images. But 52.6% recall means it missed about half the eggs in the egg images. Imagine you're doing an Easter egg hunt, and there are 19 eggs hidden in the yard. A recall of 52.6% means you only found 10 of them.

At a stricter 70% confidence threshold, recall dropped to 36.8%, so you'd only find about 7 out of 19.

I added logging to see what objects Rekognition detected for the missed eggs. The logged objects were pretty accurate, which told me that Rekognition identified the gist of the images well but couldn't "see" the Easter eggs.

I realized the out-of-the-box API was great for detecting Easter eggs in more typical scenes, like this one.

Script output:

  ✅ 1774389521556_img.png eggs: Egg (99.9%), Easter Egg (99.1%)

DetectLabels had a harder time finding Easter eggs in less obvious scenarios or with more competing objects, like this one.

Script output:

❌ MISS 1774389716587_img.png eggs: none
↳ saw instead: Toy (98.7%), Teddy Bear (93.5%), Lego Set (69.8%), 
   Plush (53.7%), Doll (48.1%), Play Area (48.0%), Handicraft (47.7%), 
   Hedgehog (46.9%)

Round 2: Custom Labels

Custom Labels exist for situations where you need to detect specific objects in specific scenes that go beyond the capabilities of DetectLabels, like my Easter egg images. With Custom Labels, you can train a computer vision model on your own images. The model can learn to spot what you care about, even when the object is small, partially hidden, or surrounded by lots of visual noise. The benefit here is that rather than training a computer vision model from scratch on tens of thousands of images, you can build on existing capabilities by just uploading a relatively small set of training images. Then, Rekognition handles the model training and evaluation process for you.

I did this all directly in the Amazon Rekognition console, where I created a new project and uploaded my dataset of images. Rekognition automatically split my data 80/20 for training and testing.

I created my custom label of "Easter egg" and drew bounding boxes around the Easter eggs in my dataset images, then hit Train.

Training took around 30 minutes. When it finished, I got a model ARN and performance metrics. Here's how the custom model did on the test dataset compared to the standard DetectLabels API:

Metric	DetectLabels (30% threshold)	Custom Labels
Precision	100%	77.80%
Recall	52.60%	75%
F1 score	(not calculated)	0.764

Recall jumped from 52.6% to 75%. This meant that the custom model was finding eggs that DetectLabels missed entirely. Precision dropped from 100% to 77.8% (more false positives), meaning it occasionally saw an egg where there wasn’t one, but I think that's a reasonable trade-off for catching 22% more of the eggs.

The F1 score is a metric that shows how well the model balances precision and recall, indicating its overall accuracy. A score of 0.764 from a dataset of 37 images is a good starting point.

Going back to the Easter egg hunt analogy, DetectLabels was the careful egg hunter who only picked up real eggs but walked past half of them. The custom label found most of the eggs but also grabbed a few eggish-looking rocks along the way in the test dataset.

Considering the fact that I only had 37 total images in the dataset, these are promising results, but there's definitely room to improve. I'd expect the model's performance to climb if I added more training data. But this experiment was for learning and my own curiosity, and that F1 score worked for me. I plugged my custom model’s ARN into my Streamlit app, and uploaded a few images. The custom model did a pretty good job of detecting Easter eggs on new images that weren’t part of the training dataset.

It also was pretty good about not registering false positives, even with temptingly bright round objects in the image.

Cost

Everything in this project fits comfortably within the AWS Free Tier credits for new accounts. Here are some more details on the pricing for training and inferencing with a custom model in the us-east-1 region:

DetectLabels (Group 2 API)

74 images × $0.001/image = $0.074
- I had 37 images, but I ran the batch analysis script twice (first checking for egg presence, then again to log the labels that were found for false negatives).

Custom Labels training:

0.52 hours × $1/hour = $0.52
- The docs note that Amazon Rekognition may run multiple compute resources in parallel, so actual billed hours can be higher than elapsed time for model training.

Custom Labels inferencing:

1.41 hours x $4/hour = $5.71

If you build this in your own account, be sure to STOP the model when you’re done inferencing to avoid accumulating further charges. In total for this project, I was billed for 85.7 inference minutes and 31 training minutes, which amounted to $6.24. This amount was deducted from my Free Tier credits. (The charges for other services in the following cost breakdown image are related to other Free Tier projects.)

What I learned, and what I'd do differently

The jump from DetectLabels to Custom Labels was the most interesting part of this project for me. With Custom Labels, you get to label your own data, train a model, evaluate its performance, and iterate. That loop (data → train → evaluate → improve) is the same loop behind every ML system. Custom Labels just makes it accessible without needing to have ML experience or having to spin up your own dedicated hardware.

I also came away with a better sense of when to use what. You could send an image to one of the newer multimodal foundation models and ask, "Are there any Easter eggs in this picture?" It would probably give you a very good answer. But for a tightly-scoped detection task like this one, I think a purpose-built service is a better fit. A single API call returns predictable JSON with labels, confidence scores, and bounding box coordinates. No system prompt to write, no natural language to parse. And the whole project cost me $6.24 in Free Tier credits.

A couple things I'd change if I were starting over:

Create more images for the dataset. The docs say that most custom models need a few hundred images or less, but I only had 37. I'd aim for 50+ per class (Easter egg and no Easter egg). I'd also set up a script to generate text for image prompts and call an image generating API to quickly create a bunch of training and test images.
Test with real photos, not just AI-generated ones. Generated images have a certain look to them. Real phone photos with unexpected lighting and odd angles would be a tougher test.

Try it yourself

The full code and installation directions are on GitHub here.

If you want to skip the training and just play with DetectLabels, the standard mode works immediately. Upload a photo of your breakfast and see what happens. 🍳

If you want more ideas for Free Tier projects, let me know in the comments!