Nine Apps Worth Coding, and the Hard Part Buried in Each One
Every app idea has a boring 90% and a nasty 10%. The boring part is CRUD, auth, a settings page, Stripe. The nasty part is the one subsystem that decides whether the thing works at all, and it’s usually not the part that looks hard in the pitch. Below are nine builds worth attempting, with the nasty 10% named up front so you can decide whether you want to spend your weekends there.
Developer Tooling
Mock API Server From a Spec
Feed it an OpenAPI document or a plain JSON Schema, get back a running server with generated example data, fake bearer tokens, latency injection, and error responses you can trigger on demand.
The easy version is a json-server wrapper. The version people pay for understands schema composition: allOf, oneOf, discriminated unions, $ref chains that loop back on themselves. Real specs are full of these, and naive generators either crash or emit {}. Write a resolver that flattens the schema graph into a concrete type tree first, cache it, and generate from the flattened form. Do the same for format hints, because a field typed string with format: email should produce an address, and a field named created_at should produce a plausible timestamp rather than "string".
Second hard bit: statefulness. A mock that returns the same three users on every GET is a toy. Wire POST, PATCH, and DELETE into an in-memory store keyed per session token, so an integrating client can create a record and then fetch it. That single feature is the difference between a demo and a tool someone keeps a tab open for.
Stack that fits: Node with Fastify, or Go if you want single-binary distribution. Ship the CLI first, host it second.
Cookieless Analytics for Small Projects
Page views, unique visitors, referrers, a two-step or three-step funnel, and nothing else. No cookie banner, no consent flow, no 90KB script.
The interesting constraint is identifying a repeat visitor without storing anything on their device. The standard approach is a rotating daily hash of IP, user agent, and a server-side salt that you throw away at midnight. That gives you a defensible daily-unique count and makes cross-day tracking impossible by construction, which is the point. Write the salt rotation as a scheduled job that actually discards the old value rather than archiving it, because archiving it quietly turns your privacy claim into a lie.
Ingest is the scaling question. A /collect endpoint doing a synchronous row insert per hit dies at modest traffic. Buffer in memory, flush in batches, and store in something columnar. ClickHouse is the obvious answer; SQLite with hourly rollup tables is the answer that costs six dollars a month and covers every customer you’ll have in year one.
Keep the client script under 2KB. It’s the first thing anyone checks.
Repository Dependency and Complexity Visualizer
Parse a codebase, build the import graph, overlay complexity and churn, render it as something a human can actually read.
Parsing is solved. Tree-sitter gives you grammars for everything, and a resolver for each language’s module system is a day of work per language. The genuine difficulty is layout. A force-directed graph of 2,000 nodes is a hairball, and every tool that stops there gets opened once and closed. What works is hierarchical grouping by directory with collapse and expand, edge bundling so 400 imports of utils.ts read as one thick rope, and a default view that shows the top-level modules with everything else folded.
Overlay churn from git log and you get the view that pays for itself: files that are both complex and frequently modified. That’s the refactor argument, rendered. Export it as a PNG someone can paste into a planning doc and you’ve built the actual product.
Run the analysis in a worker, stream results over a WebSocket, render with Canvas rather than SVG once you pass a few hundred nodes.
Tools for Creative Work
Storyboard and Shot List Builder
A canvas where a director or a writer lays out frames in order, attaches a shot type and lens to each, writes production notes, reorders by dragging, and exports a PDF the client can scribble on.
Drag-and-drop ordering with a few hundred cards is where naive implementations fall over. Use fractional indexing for card positions so a reorder is a single field write rather than a renumbering of the whole list, and virtualize the canvas so off-screen frames aren’t mounted.
Offline matters more than it sounds. Storyboards get edited on set, on a phone, in a basement with no signal. Build local-first with a CRDT such as Yjs or Automerge, sync when the connection returns, and you also get real-time collaboration for free, which is the feature the client will ask about in the first demo.
PDF export deserves real effort. Server-side rendering through headless Chromium gives you exact fidelity with the on-screen layout and saves you from reimplementing the design twice.
Domain Portfolio Manager
Renewal dates, registrar spread, DNS and nameserver state, traffic per name, comparable sale prices, and a generated for-sale page per domain.
Anyone holding a few hundred names is running this in a spreadsheet, and the spreadsheet is wrong, because registrars don’t agree on export formats and nobody re-exports monthly. So your ingest layer is the product: registrar APIs where they exist, bulk WHOIS or RDAP where they don’t, plus a CSV importer tolerant of the six shapes the major registrars emit. RDAP is the modern path and returns JSON, but rate limits are aggressive, so queue lookups, respect backoff, and refresh a given name daily at most.
The alerting logic is where you earn trust. A missed renewal is an expensive, permanent mistake, so alerts need to fire on a schedule that assumes the user ignores the first two. Escalate: 60 days, 30 days, 7 days, 1 day, and route the last one somewhere that buzzes.
Landing page generation is a static build per name, pushed to a CDN, with a contact form that doesn’t leak the owner’s address to scrapers. Wildcard TLS and a single shared template make the marginal cost of the 400th page about zero.
Local-First Media Archive With Smart Tagging
A desktop library for a photographer or a video shooter with 200,000 files on a NAS. Reads EXIF, extracts dominant colors, notes orientation and aspect ratio, derives perceptual hashes for near-duplicate grouping, and makes all of it searchable.
Indexing is the whole engineering problem. Walking a quarter-million files and decoding each one for a thumbnail takes hours if you do it wrong. Do it in a worker pool, read embedded preview JPEGs out of raw files instead of demosaicing the full frame, write thumbnails to a content-addressed cache, and make the index resumable so a crash doesn’t restart from zero. Use a file system watcher for incremental updates afterward.
For similarity search, perceptual hashing with Hamming distance covers near-duplicates and burst frames cheaply. If you want semantic search, a small CLIP model running locally gives you vectors you can store in SQLite with a vector extension, and the whole thing stays offline, which is the reason the user chose you over the cloud service.
Tauri or Electron with a Rust or Go core. The heavy path must not run in JavaScript.
Workflow Automation for Small Operators
Client Onboarding Portal
One link. Branching intake questionnaire, file uploads, contract signature, deposit, milestone tracker. It replaces the first four emails of a project, which is exactly where scope goes undefined.
Build the questionnaire as a JSON-defined form with conditional logic rather than hardcoded screens, because every freelancer will want different questions and you do not want to ship a release per customer. Uploads go straight to object storage with presigned URLs so a 4GB video file never touches your server. E-signature can be delegated to an existing API at first, though rolling your own with a hashed document snapshot, a timestamp, an IP record, and an audit trail is legally sufficient in most jurisdictions and removes a per-envelope cost.
Make the client side work with no account. The moment you ask a new client to register, half of them stall, and the freelancer blames your product.
Itinerary Builder From Confirmation Emails
Forward it a flight confirmation, a hotel booking, and a note about a dinner reservation. It returns a timeline with map overlays, works offline on a phone, and flags the moment you’ve booked a museum 40 minutes after your train arrives.
Parsing is the moat and also the grind. Airlines send structured data in schema.org JSON-LD often enough to be worth checking first, and the rest is a long tail of HTML templates that change without warning. A language model handles the tail well, but run it behind a deterministic extractor so the common carriers never cost you a token, and always show the user what was parsed with an easy correction path. Wrong dates in an itinerary app destroy trust in one use.
Time zones will hurt. Store every event in UTC with the IATA code of its location, resolve the display zone from the code, and never trust the offset printed in the email.
Conflict detection is the feature nobody else ships: compute travel time between consecutive events and warn when the gap is short.
Container and Vessel Tracking for Small Importers
Vessel position, ETA drift, port congestion, container status, and customs paperwork in a single view for a company importing forty containers a year.
Freight forwarders already have this. Small importers find out about a two-week berth delay when the storage invoice arrives. Data comes from AIS feeds for vessel positions, carrier APIs for container events where the carrier offers one, and terminal or port authority feeds for queue depth. Coverage is uneven and formats conflict, so normalize everything into one event model early: a shipment has containers, a container has a status history, a status has a source and a confidence.
The valuable output is not the map. It’s the prediction that the published ETA is optimistic, based on the vessel’s actual speed over the last 48 hours and the berth queue at the destination. That calculation is simple arithmetic over data most importers never see, and it’s the reason someone pays monthly.
Poll on a schedule matched to how fast the underlying data moves. Vessel position every few hours, container milestones daily, and cache aggressively, because these APIs charge per call.
Choosing One
Look at the nine and notice how few of the hard parts are about frameworks. They’re about schema resolution, index throughput, layout readability, parse reliability, and data normalization. That’s where the time goes, and it’s also why these survive a competitor cloning your UI in a weekend.
Pick the one where you’re already the user. You’ll know which of the nine features matter and which seven can wait, and you’ll find the nasty 10% in week one instead of month four.