DEV Community: Marco Kohns

Building a job training site for the Philippines on free tiers, where every number has a source

Marco Kohns — Fri, 16 Oct 2026 22:31:11 +0000

TrabahoFit helps Filipino job seekers train for a specific job: what it pays, what employers ask for and what to practice first. It runs for close to zero fixed cost, and every figure on it comes from a source a reader can check. Here is how it is built.

Stack

Next.js 16 with the App Router, React 19, TypeScript and Tailwind CSS v4
Supabase (Sydney region, closest to the Philippines) with one table for quiz attempts, written only through RPCs
Vercel for hosting; production deployments are indexable, preview and local builds are not, controlled in one place

Data first, pages second

Every guide starts as a dataset in the repo: 50 call center job posts from JobStreet coded field by field (experience, education, salary, tests), 40 freelance posts from OnlineJobs.ph, 216 public e-TESDA courses, and the Department of Labor and Employment's in-demand jobs list. Each dataset has a small Python script that prints every figure the page uses, so a number on the site can be reproduced from the repo.

That's how we found that 62% of the call center posts accepted beginners (n=50) and that none mentioned the Versant test, which most preparation content focuses on.

A gate before every push

Pages follow a writing spec, and npm run build && npm run gate must pass before a push, so pages that break the content rules don't ship.

A quiz that credits its landing page

The quiz is embedded inline on every guide page and records which page it started on, so we can see which guides lead to quiz completions.

What I'd do again

Building the dataset before the page made the writing fast and the claims safe. If you want to see the result, start with the call center agent guide. Questions about the setup are welcome in the comments.

Building a price comparison site where every price comes from our own checkout runs

Marco Kohns — Fri, 16 Oct 2026 22:11:12 +0000

schliessfach24.de compares luggage lockers and luggage storage at German stations and airports. Its one rule: no advertised prices. Every number on the site comes from a checkout we ran up to the payment button, with a screenshot and a date. This post is about how that is built and kept honest.

Stack

Next.js with the App Router and Tailwind, statically generated pages per city and place (station, airport, trade fair, sight)
Supabase behind the scenes, content as typed data files per city in src/data/content/<city>/
Vercel, with main as production and a preview branch for every change

Research before code

Each city starts as a research document: every provider near a place, the checkout run for a fixed scenario (one regular suitcase, same-day drop-off and pick-up, plus an overnight case), the total including service and protection fees, the billing rule (per started 24 hours or per calendar day), opening hours, payment methods and the screenshot file names. Official sources come first: Deutsche Bahn station pages and the airport operator's price list.

The research is where the interesting findings come from. At Frankfurt Hbf, one suitcase overnight was 6.00 euros in a Deutsche Bahn locker and 11.99 or 13.65 euros through apps, because of fees and calendar-day billing. At Frankfurt Airport the apps' "airport" results were lockers 57 to 141 minutes' walk away.

A gate before every page

A content skill turns the research into the typed page data and then runs a blocking gate per city: every page needs at least one screenshot as evidence, at least two data visualisations, a FAQ with three or more questions, a visible "last checked" date and dateModified\ plus an author in the JSON-LD. It fails on noindex\, on banned words, on missing internal links inside the city cluster, and on any sentence that also appears on another city's page. Before a push, typecheck, build and an SEO audit against a local server have to pass too.

Structured data that matches the page

Each page emits one JSON-LD @graph: Organization and WebSite with stable @ids, the article with its image, a map (hasMap), and the provider list with prices and opening hours, so search engines read the same facts the visitor sees.

Keeping it fresh

Every page shows when it was last checked, and prices are re-run at least every 90 days. That cadence is the main cost of the product, and the reason it is worth trusting.

If you want to see the result, start with Frankfurt Hbf (the site is in German). Happy to answer questions about the pipeline in the comments.

Building a local course directory as a fully static Next.js site

Marco Kohns — Fri, 16 Oct 2026 17:09:20 +0000

kursvorort.de is a directory for in-person courses in Germany, starting with swimming, dance and yoga classes in 15 cities. The gap it fills: course offers are spread across municipal pools, adult-education centres, clubs and private schools, and their prices can't be compared. This post is about how it is built, and why it runs without a database, without logins and without a single form.

The stack

Next.js 15 with the App Router, React 19, strict TypeScript, Tailwind
fully static: every page is generated at build time via generateStaticParams, with dynamicParams = false
hosted on Vercel, with cookieless Vercel Web Analytics
no database and no accounts; providers get in touch by email

That sounds unusual for a directory, but it fits the content. Pages only change when the research is redone, not on every request. Static means fast pages, nothing that can fail at night, and no personal data to protect under GDPR.

Data as typed files

All content lives as typed files in src/data/: categories, cities, providers, and one content file per page such as src/data/content/tanzkurse-berlin.ts. Pages never import that data directly; they read it through one layer in src/lib/data.ts. That keeps the source swappable: once paid listings arrive, providers move into a database and no page has to change.

The URL structure follows the search terms: /{category}/{city}, so /schwimmkurse/berlin, and one level deeper /{category}/{city}/{course-type} for course types. Title, H1 and meta description come from one central pattern, and tests check their length.

Research as a pipeline with a gate

The interesting part is the path from research to page. Every city and category starts as a research document with every offer taken from primary sources: price, sessions, minutes per session, mandatory extras like pool entry or club membership, booking route, source and date. From that, the pipeline computes the all-in price per unit (45 minutes for swimming, 60 minutes per person for dance and yoga) and the median per provider type.

Before a page is allowed into the build, a blocking gate runs:

every number in the text needs a source with a date, and every table needs a source line right below it
external links in editorial text must be nofollow, and a page needs a minimum number of distinct source domains
no ratings or stars in the text, and no future dates in the prose (those go into course-start blocks that expire on their own)
no sentence may appear word for word on another city page, and every city needs sections of its own
FAQ schema, a visible "last checked" date and required blocks like the price comparison and the calculator, plus typecheck, tests, build, an SEO audit against the local server and a mobile check

Only when everything passes does the page get built.

Indexing only with content

A city page is indexable only if it has editorial content or at least three approved providers. Otherwise it gets noindex,follow and stays out of the sitemap. Internal links only point to indexable pages, and cities without research show as "coming soon" without a link. The sitemap is generated from the same data and currently lists 96 URLs.

No redirects, ever

kursvorort had an earlier version built with Lovable, with its own URLs. The rebuild kept every existing URL exactly as it was: a test checks the old sitemap for status 200 without a redirect and for a self-referencing canonical. Routes that are no longer needed simply aren't built and return 404.

What I take from it

For a directory whose value is verified data, a static site with data files and a gate is the simplest architecture that holds up. The complexity sits in the research and in the rules the gate enforces, which is where it belongs.

If you want to see the result, start with dance classes in Berlin (the site itself is in German). Happy to answer questions about the pipeline in the comments.

Product-Channel Fit Is Why Your Lovable App Has No Users

Marco Kohns — Tue, 27 Jan 2026 10:35:05 +0000

Most builders talk about product-market fit. Few talk about product-channel fit.

Product-channel fit asks a different question:
Does this product naturally acquire users through a specific channel without brute force?

If the answer is no, your MVP is incomplete.

A Lovable app built without a channel in mind often looks fine but fails in predictable ways:

No indexable pages for SEO
No lead capture for outbound
No onboarding logic for PLG
No feedback loop to measure activation

These are not marketing issues. They are product decisions that were never made.

In our workflow, the channel is selected first. The MVP then inherits the requirements of that channel.

That single constraint eliminates most early-stage confusion. You are no longer guessing what to build next. The channel tells you.

We codified this workflow into Lovable Prompts so the output prompt already includes distribution requirements alongside features and tech.

If your app cannot explain how it gets users, it is not done yet.

The full breakdown is in the free Distribution-First Lovable Prompting Handbook. You can access it for free here: lovable-prompts.com