DEV Community: Kevin Coto🚀💡

Building a LINE First Fitness Agent with AI Cost Gates

Kevin Coto🚀💡 — Wed, 15 Jul 2026 01:04:49 +0000

It Started in Thailand

I built Fit Homie for LINE because that is what everyone in Thailand uses. If you want to reach people in Bangkok, you build on LINE. It is not a choice, it is the reality of the market.

The idea was simple. Snap a photo of your meal, send it to the bot, get back the nutritional breakdown. No app downloads, no complex logging. Just open the chat app you already use and take a picture.

The First Real Users

I tested it with my ex girlfriend and a group of friends. They got hooked. They were sending photos of every meal, comparing nutrition, tracking their progress. It was the first time I saw people actually stick with a fitness tool.

But then they started noticing the cracks. What if they wanted to log a meal on a desktop? What if they wanted to share their progress with someone who did not use LINE? What if LINE went down?

The chat app was both the reason it worked and the reason it could not scale.

The Cost Problem Nobody Thinks About

Before I launched, I calculated what it would cost if people actually used this thing. Every meal photo meant an AI inference call. If a hundred users logged three meals a day, that was three hundred API calls daily. At scale, the costs would eat any possible revenue.

I built a five layer cost optimization pipeline. Exact match cache for the same photo. Fuzzy match for similar meals. A precomputed database of ten thousand common foods. A local LLM fallback before hitting the paid API. Rate limiting and batching for the paid tier.

This cut AI costs by roughly eighty percent compared to calling the API directly every time.

From Chat Bot to Mobile App

The feedback from early users was clear. The concept was right but the delivery was limited by the platform. People wanted a real app. They wanted to see charts, set goals, track progress over time. Things a chat bot cannot do well.

So Fit Homie is now becoming a mobile app. The LINE bot still exists and handles quick meal logging. The app adds the depth that the chat interface cannot provide. Progress tracking, nutrition analytics, goal setting, history.

The bot is the front door. The app is the home.

What I Used

Django backend with LINE Messaging API. Gemini AI for food recognition. Next.js dashboard for analytics. Stripe for subscriptions. PostgreSQL for everything else.

A Polyglot Feedback Platform: Django, Next.js, and Elixir Working Together

Kevin Coto🚀💡 — Wed, 15 Jul 2026 01:03:53 +0000

The Waiter Who Wanted to Give Feedback

I worked as a waiter. I also love food. That combination gave me a weird perspective on restaurants. I saw how much effort went into the food and service, but I also saw the gap between what customers thought and what restaurant owners knew.

Sometimes I wanted to tell a restaurant about an issue I noticed. Not to complain publicly, not to hurt their reputation. Just to help them improve. But there was no easy way to do that. Either I told a manager directly which felt confrontational, or I left a public review which felt destructive.

I wanted a middle ground. A way to give feedback that reached the right people without the public shaming.

Three Languages for Three Jobs

The architecture was intentional. Each piece of the system has different needs and I picked the best tool for each one.

Django handles the backend and the admin interface. It has the most mature ORM I have used and the admin panel is ready to go out of the box. For a system that needs to manage restaurants, feedback, and users, Django was the obvious choice.

Next.js powers the customer facing form and the business dashboard. Restaurants in Bangkok serve a multilingual customer base. The frontend needed to handle multiple languages elegantly and Next.js with SSR delivers a fast experience on any device.

Elixir with Oban handles background jobs. Email notifications, weekly digest generation, analytics aggregation. Oban makes job processing simple and reliable. If a job fails it retries. If traffic spikes it queues. The concurrency model handles everything without breaking a sweat.

The Moment It Worked

The first restaurant that used KraowKao saw real feedback come in. Not the usual public reviews that are either five stars or one star with no middle ground. Structured, honest feedback about specific things.

They got excited because they could improve their service before it turned into a public complaint. A customer mentioned the music was too loud and they adjusted it the same day. Another mentioned a dish was undersalted and the chef fixed it for the next order.

That is the whole point. Not to replace public reviews, but to give restaurants a chance to fix things before those reviews happen.

What It Does

Customers scan a QR code on the table and answer a quick structured form. No account needed, no app download. The feedback goes directly to the restaurant dashboard where they can respond and track trends over time. Everything is private between the customer and the business.

The Tech

Django REST Framework for the API. Next.js for the multilingual frontend. Elixir with Oban for background job processing. PostgreSQL for everything.

Building an AI Accountability Coach That Knows Your Habits

Kevin Coto🚀💡 — Wed, 15 Jul 2026 01:03:50 +0000

I Wanted to Fix My Calendar

I had a problem. My calendar was chaotic. Meetings scattered across the day, deep work interrupted, and no easy way to see what my week actually looked like. I wanted something that could help me organize my time without me having to think about it.

That is where PIA Coach started. Not as a grand AI experiment. Just as a tool to help me manage my own calendar better.

Learning Patterns Over Time

The first version was simple. It tracked when I completed tasks and when I procrastinated. Over time it started noticing patterns. I was most productive in the mornings after coffee. I procrastinated hardest around 3pm. On days after bad sleep, I struggled to start anything.

I built the circadian inference system to learn these patterns automatically. It watches when you complete tasks, when you start them, when you avoid them. After enough data, it knows when to push you and when to back off.

The key insight is that productivity is not about willpower. It is about timing. If you try to do deep work at 3pm when your energy is low, you will fail. PIA learns your energy cycles and schedules around them.

The Moment It Got Real

Several times PIA called me out and I actually listened. It sent a message saying "you have been avoiding that task for three days. You have 30 minutes before your next meeting. Start now."

The reason I listened was not because the bot was smart. It was because it was right. It had been tracking me long enough to know my patterns better than I did. When it told me I was procrastinating, I could not argue because the data was there.

How It Works

PIA runs on Telegram with a Python backend. DeepSeek powers the coaching conversations. The behavioral profiling engine tracks every interaction and builds a model of your motivation patterns. Google Calendar integration gives it awareness of your schedule.

The plugin architecture means new coaching modules can be added without touching the core. Each plugin handles a specific area. Habit tracking, deep work sessions, procrastination detection. The core engine learns from all of them.

What Makes It Different

Most productivity tools are reactive. You set a reminder and it goes off at the time you chose. PIA is proactive. It knows when you are about to procrastinate and steps in before you do. It adapts its tone based on what works for you. Some people need tough love. Others need encouragement. PIA figures out which one you respond to.

Building a Multi Platform AI Budget Coach

Kevin Coto🚀💡 — Wed, 15 Jul 2026 01:03:20 +0000

The Problem Was Me

I was making more money but my savings were not going up. Every raise just meant I spent more. I tried every budgeting app on the market. They all worked for a week then I forgot about them.

The pattern was always the same. Download app, enter expenses for three days, get bored, uninstall. The apps required too much work. I had to open them, navigate menus, fill forms. When I was tired after work, I was not going to do that.

I realized the problem was not my spending. It was the tools. If budgeting required effort, I was not going to do it consistently.

Meet People Where They Are

I wanted to build something that required zero effort. No app to open, no dashboard to check, no forms to fill. Just send a message like you already do hundreds of times a day.

But people use different apps. In some countries everyone is on WhatsApp. In others it is Telegram. Developers live on Discord. If I picked one platform, I would miss everyone else.

So I built for all three. Same backend, same AI, same budget logic. The only difference is the messaging adapter on top.

The Moment It Clicked

The first time someone typed "spent 45 on dinner" and the bot replied with their remaining budget, their reaction was genuine surprise. It felt like magic because there was nothing to learn. No onboarding, no tutorial, no setup. Just type what you spent and it works.

That is when I knew the concept was right. Not because the technology was impressive, but because it disappeared. The user did not feel like they were using a budgeting tool. They were just texting a friend who happened to track their money.

How It Works

FastAPI handles the backend. Each messaging platform has its own adapter that normalizes messages into a common format. The NLP layer parses natural language and extracts amounts, categories, and intent. PostgreSQL stores everything.

The user types "spent 45 on groceries" and the bot logs it, updates the category budget, and replies with a confirmation and remaining balance. No forms, no fields, no friction.

Where It Is Now

DIA works across Telegram, WhatsApp, and Discord. It handles expense logging, budget tracking, savings goals, and spending analytics delivered as weekly digests. The natural language understanding improves over time as it learns how each user talks about their money.

Building a Voice AI Receptionist for Restaurants

Kevin Coto🚀💡 — Wed, 15 Jul 2026 01:03:18 +0000

The Problem That Wouldnt Let Go

I spent time in restaurants. Not as a consultant, not as a tech person observing from the corner. I worked in them. I saw how the phone rang during the lunch rush and nobody could pick it up because everyone was running food, seating guests, handling complaints.

Big chains have the same problem as family owned spots. The person who answers the phone is also managing the floor. When they are taking a reservation, they are not helping the customer standing in front of them. When they are helping that customer, the phone rings and a potential booking walks away.

I wanted to fix that one thing. Not build another POS system, not another reservation platform. Just let the restaurant answer every call without needing a dedicated receptionist.

The Integration Nightmare

The hard part was never the AI itself. It was making everything talk to each other.

A phone call comes in through Twilio. That needs to connect to Vapi for the voice agent. The voice agent needs to call my backend to check availability and book reservations. Tool calling needs to happen inside the call in real time without noticeable delay. The backend needs to update the database and send confirmation messages.

Getting all of that to work together took longer than anything else. Webhooks from Twilio needed to reach Vapi at the right moment. Vapi needed to trigger tool calls on my FastAPI server while the caller was still talking. The timing had to be tight enough that the caller never noticed they were talking to a chain of APIs.

I hit a point where I questioned whether it was worth it. Every platform has its own quirks, its own timeout limits, its own idea of how a webhook should look. Getting them to agree took weeks of trial and error.

The Moment It Clicked

Then it worked. A real call came in. The AI answered, asked the right questions, used tool calling to check available times, and wrote the reservation into the database. No human involved.

Watching that first successful end to end flow changed something. It was not just that the technology worked. It was that the restaurant could have answered that call while short staffed during a lunch rush. The caller got their reservation. The staff stayed focused on the floor.

That moment made all the integration headaches worth it.

Where It Is Now

Vozko is still in beta. It has been tested in short one day operations to validate the flow. The AI handles reservations, menu questions, and hours of operation. When it cannot handle something, it escalates to a human through SMS.

The next step is getting it into a restaurant for a full week of real operations. Let it take the pressure of the lunch rush and see how many calls it can handle before needing to escalate.

What I Used

FastAPI for the backend that handles Twilio webhooks and orchestrates Vapi. Twilio for the phone system itself. Vapi for the voice AI agent that talks to callers. PostgreSQL for reservations and call logs. Next.js for the management dashboard where restaurants can see call history and reservation data.

Building a Reusable Chat Infrastructure with DynamoDB Single Table Design

Kevin Coto🚀💡 — Wed, 15 Jul 2026 00:51:11 +0000

The Problem That Kept Coming Back

Every project eventually needed chat. Customer support, collaboration, real time updates. I built chat for one project, then another, then another. Each time I wrote similar code with slightly different data models. It was wasteful.

I decided to build chat infrastructure once and reuse it everywhere. A single DynamoDB table that could power real time messaging for any application.

The Single Table Design

The entire chat system lives in one DynamoDB table. The key structure is simple.

The primary key is the conversation ID combined with a timestamp as the sort key. This lets me query all messages in a conversation in order. The global secondary index maps users to their conversations so I can show someone their full chat history with a single query.

That is it. Two access patterns. One table. No joins, no complex queries, no denormalization headaches.

Why DynamoDB

PostgreSQL would have worked but it would have required connection pooling, read replicas at scale, and ongoing maintenance. DynamoDB needs none of that. You provision the throughput and it handles the rest.

For chat, the access patterns are well known and stable. You always query by conversation or by user. Those patterns never change. DynamoDB rewards you when you know your access patterns upfront and design around them.

Real Time Delivery

Messages written to DynamoDB trigger a stream event. A Lambda picks up the event and broadcasts the message to all connected WebSocket clients through API Gateway. The client receives the message without polling.

The system handles disconnections gracefully. If a client drops, the message stays in DynamoDB and gets delivered when they reconnect.

What I Built

A reusable chat module that any application can integrate. The same infrastructure powers chat across multiple projects with zero changes to the core code. Each application gets its own conversation namespace but shares the same DynamoDB table, the same WebSocket endpoint, and the same broadcast logic.

Designing a Three Reviewer Consensus Platform for Digital Harm Reporting

Kevin Coto🚀💡 — Wed, 15 Jul 2026 00:50:41 +0000

Agency Work for the South African Government

I was freelancing through an agency and ended up working on a platform for the South African government. Real411 is where citizens report digital harms. Disinformation, hate speech, online harassment. The kind of content that poisons public discourse.

The responsibility was heavy. Every report needed to be handled carefully because getting it wrong meant either letting harmful content stay up or silencing legitimate speech. There was no room for error.

Why Three Reviewers

A single reviewer could be biased. Two reviewers could disagree and deadlock. Three gave us a system where consensus was possible without being impossible to reach.

Each reviewer comes from a different category. Different sectors, different expertise. A legal expert, a technical expert, a community representative. They evaluate the same report independently and cannot see each other's decisions until all three have submitted.

More importantly, reviewers from different categories cannot communicate outside the platform with each other. They do not know who the other reviewers are. They do not work for the same organization. This isolation prevents collusion and ensures each decision is truly independent.

The AI Problem

We wanted to use AI to help reviewers by providing summaries and overviews of reports. But when you are dealing with sensitive content, AI introduces risks. What if the summary misses a crucial detail? What if the AI hallucinates something that influences the reviewer's decision?

We had to be extremely careful about where we placed AI in the workflow. It could help triage and organize, but it could never make or suggest a decision. The human reviewers remained the sole authority on every case.

How the Workflow Works

A report comes in and gets assigned to three reviewers from different categories. Each reviews independently. If at least two of three agree on the outcome, the decision is applied automatically. If there is no consensus, it escalates to a senior reviewer.

Timeouts ensure no report gets stuck. If a reviewer does not respond within twenty four hours, the report is reassigned. The entire process is tracked and auditable.

What I Built

React frontend for the reviewer dashboard. Node.js API layer. PostgreSQL with row level security to ensure reviewers can only see their own assignments. AWS Step Functions to orchestrate the workflow. SQS and SNS for event driven processing between components.

Building a Real Time Sports Scoring Engine with WebSockets and DynamoDB Streams

Kevin Coto🚀💡 — Wed, 15 Jul 2026 00:49:11 +0000

Tennis Courts in South Africa

The project started with tennis courts in South Africa. Local tournaments needed a way to display live scores that everyone could see. Not just on a central board, but on phones, on screens around the court, anywhere people wanted to follow the match.

From there it grew to cover other sports. The core problem was the same regardless of the game. A point happens, the score changes, and everyone needs to see it instantly.

Why DynamoDB Was the Key

I tried other approaches first. Relational databases could handle the data but could not guarantee the latency we needed. In memory stores were fast but added complexity for persistence.

DynamoDB was the answer because it does one thing well. You ask for data by a key and you get it back in single digit milliseconds. No query optimization, no connection pooling, no read replicas. Just fast predictable access.

The single table design meant every access pattern was a simple key lookup. Get all messages in a conversation. Get all conversations for a user. Paginate by timestamp. Each query was fast because the table was designed around the queries, not around the data.

How Real Time Works

When a score happens, it goes through API Gateway to a Lambda that writes it to DynamoDB. DynamoDB Streams captures the change and triggers another Lambda. That Lambda broadcasts the update to every connected WebSocket client.

The entire pipeline from score event to spectator screen takes under a tenth of a second.

It Worked Flawlessly

The first time it ran during a real tournament, it just worked. Scores appeared on screens around the court instantly. People watching from home saw updates at the same time as people sitting courtside.

No missed updates. No duplicate points. No delays. The system scaled from a single match to multiple courts without any degradation.

What I Used

AWS API Gateway WebSocket for real time connections. Lambda for score processing and broadcast logic. DynamoDB for persistence with single table design. DynamoDB Streams for change data capture. Svelte for the spectator displays and scoring controls.

Migrating a Production Platform from CDK to SST Without Downtime

Kevin Coto🚀💡 — Wed, 15 Jul 2026 00:48:21 +0000

When CDK Was Not Enough

Restore Blue helps organizations manage coastal restoration projects. Millions of trees, complex tracking, real impact data. The infrastructure was built on AWS CDK and it worked. But as the platform grew, the limitations became hard to ignore.

CDK is powerful but developing with it is slow. Every change requires a full deployment. There is no way to test a Lambda function locally with real infrastructure. You write code, deploy, wait, check logs, repeat.

SST changed that. Live Lambda development meant I could see changes instantly. Resource bindings gave me type safe references between infrastructure and application code. The developer experience was significantly better.

The Migration Strategy

The key was running both stacks in parallel. The CDK stack kept serving production traffic while the SST stack was built and validated alongside it.

Phase one was deploying the SST stack with the same resources as the existing CDK stack. Phase two was routing new traffic to SST resources. Phase three was validating that SST handled every workload correctly. Phase four was decommissioning the CDK stack.

The Tricky Parts

DynamoDB tables needed to be recreated with SST naming conventions without losing data. That required a careful export and import process validated multiple times before the production cutover.

Route53 records needed to switch from CDK to SST resources atomically. One wrong DNS change could take the entire platform offline.

The team needed to coordinate feature freezes around migration windows. Every migration run needed to be scheduled, communicated, and executed cleanly.

Testing Saved Us

I ran the full migration in staging three times before attempting production. Each run uncovered something. A missing permission, a misconfigured environment variable, a Lambda function that referenced the old resource name.

By the time we did the production migration, it was routine. Thirty minutes of work and the CDK stack was decommissioned. Zero downtime, zero data loss.

What I Learned

Parallel stacks are safer than big bang migrations. Run both, validate the new one, then turn off the old one. Automate your validation. If you can test it in a script, test it in a script. And run the migration more times than you think you need to.

From Dubai to Thailand: How I Landed a Remote Role at a South African Company

Kevin Coto🚀💡 — Wed, 15 Jul 2026 00:28:06 +0000

The Next Chapter

When I left the waiter job and returned to engineering, I knew I wanted something different. Not just a different job, but a different way of working. The kind where your location does not limit the problems you can solve.

I found that in Thailand, working for a South African company called Exonic.

Why Bangkok

After Dubai, I wanted somewhere with a lower cost of living where I could build runway while working remotely. Bangkok checks that box. The city is a hub for remote engineers. The internet is fast. The infrastructure works. The street food is better than any restaurant I have ever worked in.

I arrived with a laptop and a clear goal: find a remote role where I could work on meaningful projects without being tied to a physical office.

Landing the Role at Exonic

Exonic is a technology consulting company based in South Africa. They serve clients across multiple industries and geographies. When I found the opening, it matched exactly what I was looking for: full time remote, exposure to diverse projects, and the chance to work across the full stack.

The interview process was practical. System design discussions, technical assessments focused on AWS and modern frontend frameworks, and conversations about how I approach end to end delivery.

I got the offer and accepted it immediately.

As a full time remote employee, I was embedded in Exonic's engineering team. My day to day involved building cloud native solutions for their clients, designing architectures on AWS, and shipping production systems across the entire stack. The team was distributed, and the work required communicating clearly across time zones.

Three Continents Through One Company

Exonic's client base spans the globe. Over my time there, I built production systems touching three different continents.

One project was Scoring AI, a voice enabled match scoring application for sports courts. Players start a match, share a link, and control the scoreboard using voice commands. I worked on the full stack: the real time scoring engine, voice command processing, the shareable match link flow, and the responsive display that works on phones, tablets, and court side screens. The stack was Svelte on the frontend with a Node backend deployed on AWS.

Another project was My IBD Pal for Ferring Malaysia, a healthcare application for patients with inflammatory bowel disease. This involved building patient facing interfaces and clinical backend systems, processing health data securely, and integrating with healthcare infrastructure in the Malaysian market. The project is protected and not publicly accessible.

I also worked on Real411, a digital complaints platform for Media Monitoring Africa in South Africa. The platform allows citizens to report digital offenses, track complaint status, and supports media regulation workflows. Full stack development, from the submission forms to the admin dashboard and trend analytics. This project is also under restricted access.

Each project had different business contexts, different regulatory requirements, and different user bases. The engineering principles remained the same: understand the domain, design the solution, ship it, document it.

The AWS Solutions Architect Certification

Working across multiple AWS projects for different clients made one thing clear: I needed a formal credential that backed up the experience. The AWS Solutions Architect certification is the industry standard for cloud architecture knowledge.

I studied for six weeks. Not because the material is difficult, but because the scope is wide. Compute, storage, networking, databases, security, cost optimization. Each domain has multiple services and multiple trade offs.

The exam is scenario based. You are given a business requirement and you choose the architecture that meets it. Not just which service, but why. The certification forces you to think in trade offs: cost versus performance, latency versus durability, managed versus self hosted.

Passing it validated the patterns I had been applying in production for Exonic's clients. The theory matched the practice.

End to End Ownership

One of the best parts of the role was the scope. Exonic trusted me with full projects, not just isolated tickets.

An end to end project looked like this:

Discovery. Understand the business domain. What problem are we solving? Who are the users? What are the constraints?
Architecture. Choose the stack and design the system. Document the rationale.
Implementation. Build it. Write tests. Set up CI/CD.
Deployment. Put it in production. Configure monitoring and alerts.
Handoff. Document everything. Train the team. Transfer ownership.

The AWS certification helped with step two. The experience working across different client contexts helped with step one. The discipline of shipping consistently helped with steps three through five.

What Changed

When I was in Cuba, I was a good engineer with limited options. When I was in Dubai working as a waiter, I was someone starting from zero in a new country. When I landed in Bangkok and joined Exonic, I was someone who had learned that the ceiling is not set by your location.

It is set by your ability to deliver.

Employers do not care where you log in from. They care whether the code compiles, the deployments succeed, and the systems stay up. If you can do that consistently, you can work from anywhere.

What I Learned

Full time remote is different from freelancing. Freelancing gives you flexibility. A full time remote role gives you stability, team structure, and exposure to larger projects. Both are valid, but they require different mindsets.

A South African company hiring someone in Thailand to build for clients in Malaysia, South Africa, and beyond is not unusual anymore. Geography is no longer a constraint. The companies that understand this win access to global talent.

Specific projects teach more than generic ones. Scoring AI taught me about real time voice processing on the web. My IBD Pal taught me about healthcare data compliance. Real411 taught me about building for media regulation workflows. Each project expanded my context, not just my tech stack.

Certifications validate what you already know. They are not a replacement for experience. But they make it easier to get past the first screening call.

Full ownership changes how you build. When you own the entire lifecycle, you design differently. You think about deployability from day one. You write documentation as you go. You build systems that do not require you to be on call forever.

I started my career in Cuba. I worked as a waiter in Dubai. I moved to Thailand and joined a South African company building for clients across three continents. The path was not linear, but it was worth it.

Integrating Cloudflare Turnstile with SvelteKit Forms

Kevin Coto🚀💡 — Sun, 30 Mar 2025 15:29:59 +0000

The Problem

Bot protection is essential for any public facing form. Cloudflare Turnstile offers a privacy friendly alternative to traditional CAPTCHAs: no image grids, no traffic analysis, just a lightweight challenge that runs in the background.

When you pair it with SvelteKit's use:enhance for progressive form enhancement, you hit a subtle issue. Turnstile tokens are single use. After a successful submission, the old token is consumed. The next submission attempt fails because the widget still holds the spent token. The page does not reload (that is the whole point of use:enhance), so the widget never gets a chance to issue a fresh one.

This guide walks through a complete SvelteKit integration with server side validation, client side token refresh, and multiple submission support.

Server Side Validation

Turnstile verification must happen on the backend. A client side check alone can be bypassed.

Backend (`+page.server.ts`)

import { SECRET_TURNSTILE_KEY } from '$env/static/private';

async function validateToken(token: string): Promise<boolean> {
  const response = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      secret: SECRET_TURNSTILE_KEY,
      response: token
    })
  });
  const data = await response.json();
  return data.success;
}

export const actions = {
  default: async ({ request }) => {
    const formData = await request.formData();
    const token = formData.get('cf-turnstile-response')?.toString() || '';

    if (!token || !(await validateToken(token))) {
      return { success: false, message: 'Verification failed. Please try again.' };
    }

    return { success: true, message: 'Form submitted successfully.' };
  }
};

A few things worth noting here.

Turnstile returns the token as cf-turnstile-response by default. That field name is configurable if you need to avoid collisions.

The siteverify endpoint expects URL encoded form data, not JSON. This is a common gotcha when using fetch with the default JSON content type.

Store the secret key in a .env file as SECRET_TURNSTILE_KEY and reference it through SvelteKit's $env/static/private module. Never expose it to the client.

Frontend Integration

The client side uses the svelte-turnstile package which wraps the Turnstile widget as a Svelte component.

npm install svelte-turnstile

Frontend (`+page.svelte`)

<script lang="ts">
  import { Turnstile } from 'svelte-turnstile';
  import { enhance } from '$app/forms';

  let captchaKey = $state(0);
  let { form } = $props();

  $effect(() => {
    if (form) {
      captchaKey += 1;
      form = null;
    }
  });
</script>

<form method="POST" use:enhance>
  {#key captchaKey}
    <Turnstile siteKey={import.meta.env.VITE_TURNSTILE_SITEKEY} />
  {/key}
  <button type="submit">Submit</button>
</form>

Why the Key Block Works

SvelteKit's use:enhance intercepts the form submission and updates the page without a full navigation. The Turnstile widget holds a token that has now been spent.

The {#key captchaKey} block tells Svelte to destroy and recreate its children whenever captchaKey changes. Incrementing the counter inside the $effect forces a fresh Turnstile widget to mount with a new token.

No setTimeout, no mount/unmount races, just a counter increment.

Environment Variables

You need two keys from the Cloudflare Turnstile dashboard.

VITE_TURNSTILE_SITEKEY=0x4AAAAAA...    # public, exposed to browser
SECRET_TURNSTILE_KEY=0x4AAAAAA...       # private, server only

The VITE_ prefix makes the variable available to client side Vite bundles. The un-prefixed version is loaded through $env/static/private and never leaves the server.

Production Considerations

Token expiry. Turnstile tokens expire after 300 seconds. If a user fills out a long form, the token may become invalid by the time they hit submit. Consider implementing a periodic refresh mechanism for forms with long completion times.

Rate limiting. The /siteverify endpoint does not have built in rate limiting. Implement your own per IP or per session limits to prevent abuse.

Accessibility. Turnstile runs a non interactive challenge by default. If the challenge fails, it falls back to a visible widget. Test this flow with keyboard only navigation and screen readers.

Multiple forms on one page. Each Turnstile instance needs a unique widget ID. The svelte-turnstile component handles this internally, but verify that your page layout does not share instances between forms.

Summary

Turnstile tokens are single use and require a fresh widget after each submission.
Server side validation is mandatory. Never trust the client alone.
The mount/unmount pattern in $effect solves the token refresh problem cleanly.
Environment variables keep your keys separated by environment.

This setup gives you a secure, bot protected form that works with SvelteKit's progressive enhancement.

LeetCode 35: Search Insert Position. Binary Search vs Linear Scan

Kevin Coto🚀💡 — Fri, 14 Mar 2025 19:50:34 +0000

The Problem

Given a sorted array of distinct integers and a target value, return the index where the target would be inserted to maintain order. If the target already exists, return its index.

Input: nums = [1, 3, 5, 6], target = 5
Output: 2

Input: nums = [1, 3, 5, 6], target = 2
Output: 1

Input: nums = [1, 3, 5, 6], target = 7
Output: 4

The problem is straightforward on the surface, but the constraints reveal its intent. The array is sorted, and the operation needs to complete efficiently.

A Linear Solution

A linear scan checks each element until we find the insertion point.

var searchInsert = function(nums, target) {
  for (let i = 0; i < nums.length; i++) {
    if (nums[i] >= target) return i;
  }
  return nums.length;
};

This works but runs in O(n) time. For an array of 10,000 elements, the worst case iterates through all of them. The problem expects a solution that exploits the fact that the input is sorted.

Binary Search

Binary search divides the search space in half at each step. It runs in O(log n) time, which means finding an element in a million entries takes at most 20 comparisons instead of a million.

The algorithm maintains three pointers: left, right, and mid. At each step we check the middle element. If it matches the target, we are done. If the target is smaller, we discard the right half. If larger, we discard the left half.

When the loop ends without finding the target, left points to where the target should be inserted.

var searchInsert = function(nums, target) {
  let left = 0;
  let right = nums.length - 1;

  while (left <= right) {
    const mid = Math.floor((left + right) / 2);

    if (nums[mid] === target) {
      return mid;
    } else if (nums[mid] < target) {
      left = mid + 1;
    } else {
      right = mid - 1;
    }
  }

  return left;
};

Why the Insertion Point Works

When the loop exits, left has crossed right. The element at left is the first element greater than the target (or left equals the array length if the target belongs at the end). This is exactly the insertion position.

The invariant nums[right] < target < nums[left] holds at the point of exit. Visualizing this helps. Try tracing through [1, 3, 5, 6] with target = 2:

Step 1: left=0, right=3, mid=1, nums[1]=3 > 2, go left
Step 2: left=0, right=0, mid=0, nums[0]=1 < 2, go right
Step 3: left=1, right=0, exit loop, return left=1

The index 1 is where 2 fits between 1 and 3.

Edge Cases

Target smaller than all elements. The algorithm returns 0, which is correct.

nums = [10, 20], target = 5
left=0, right=1, mid=0, nums[0]=10 > 5, right=-1, exit, return 0

Target larger than all elements. The loop shifts left past the last index and returns nums.length.

nums = [10, 20], target = 30
left=0, right=1, mid=0, nums[0]=10 < 30, left=1
left=1, right=1, mid=1, nums[1]=20 < 30, left=2
exit, return 2

Single element arrays. The algorithm handles these with no special cases.

nums = [5], target = 3
left=0, right=0, mid=0, nums[0]=5 > 3, right=-1, exit, return 0

Complexity

Approach	Time	Space
Linear scan	O(n)	O(1)
Binary search	O(log n)	O(1)

Binary search matches the problem's constraints and is the expected solution. The space complexity is constant because we only store three integers regardless of input size.

Takeaways

Binary search is one of those patterns that seems trivial on paper but requires careful pointer management in practice. The off by one errors are common. The key is tracking the invariant: the condition for moving left and right must be consistent, and the exit condition must guarantee that left is the answer.

Practice this pattern on a few variations:

Standard binary search (find exact match)
Lower bound (first position where element could be inserted)
Upper bound (last position where element could be inserted)

Each variant adjusts the pointer movement rules slightly. Understanding one makes the others click.

DEV Community: Kevin Coto🚀💡

Building a LINE First Fitness Agent with AI Cost Gates

It Started in Thailand

The First Real Users

The Cost Problem Nobody Thinks About

From Chat Bot to Mobile App

What I Used

A Polyglot Feedback Platform: Django, Next.js, and Elixir Working Together

The Waiter Who Wanted to Give Feedback

Three Languages for Three Jobs

The Moment It Worked

What It Does

The Tech

Building an AI Accountability Coach That Knows Your Habits

I Wanted to Fix My Calendar

Learning Patterns Over Time

The Moment It Got Real

How It Works

What Makes It Different

Building a Multi Platform AI Budget Coach

The Problem Was Me

Meet People Where They Are

The Moment It Clicked

How It Works

Where It Is Now

Building a Voice AI Receptionist for Restaurants

The Problem That Wouldnt Let Go

The Integration Nightmare

The Moment It Clicked

Where It Is Now

What I Used

Building a Reusable Chat Infrastructure with DynamoDB Single Table Design

The Problem That Kept Coming Back

The Single Table Design

Why DynamoDB

Real Time Delivery

What I Built

Designing a Three Reviewer Consensus Platform for Digital Harm Reporting

Agency Work for the South African Government

Why Three Reviewers

The AI Problem

How the Workflow Works

What I Built

Building a Real Time Sports Scoring Engine with WebSockets and DynamoDB Streams

Tennis Courts in South Africa

Why DynamoDB Was the Key

How Real Time Works

It Worked Flawlessly

What I Used

Migrating a Production Platform from CDK to SST Without Downtime

When CDK Was Not Enough

The Migration Strategy

The Tricky Parts

Testing Saved Us

What I Learned

From Dubai to Thailand: How I Landed a Remote Role at a South African Company

The Next Chapter

Why Bangkok

Landing the Role at Exonic

Three Continents Through One Company

The AWS Solutions Architect Certification

End to End Ownership

What Changed

What I Learned

Integrating Cloudflare Turnstile with SvelteKit Forms

The Problem

Server Side Validation

Backend (+page.server.ts)

Frontend Integration

Frontend (+page.svelte)

Why the Key Block Works

Environment Variables

Production Considerations

Summary

LeetCode 35: Search Insert Position. Binary Search vs Linear Scan

The Problem

A Linear Solution

Binary Search

Why the Insertion Point Works

Edge Cases

Backend (`+page.server.ts`)

Frontend (`+page.svelte`)