How long does it take to build the parts every app needs?
\n\nFor a competent developer starting from an empty directory, 21 to 43 working days before a\ncustomer can do anything useful. That covers only the core: sign-in, payments, keeping customers\nseparate, email, background jobs, hardening, and deployment. Add mobile apps and the pages that make\nyou findable and it is closer to 34 to 68 days. This post checks those numbers against a real\ncodebase, area by area.
\n\nEvery figure below comes from this codebase, counted with wc -l on the working tree and\nbin/rspec --dry-run for the test count. Nothing is estimated after the fact.
Two caveats, stated up front. Line counts include comments, and this codebase comments heavily.\nAnd lines are a weak proxy for effort: one hard twenty-line method can cost more than two\nhundred easy ones. The day ranges are judgement, not measurement. The line counts are the evidence.
\n\nSo read this as the shape of the work rather than a stopwatch: which parts are large, which are\nsmall, and which are nothing like the size people assume.
\n\nPasswordless sign-in with Google and Apple sounds like an afternoon and a gem. The repository holds\n705 lines of application code across 19 files, and 377 lines of tests running 39 examples.
\n\nHere is where the rest of the time goes:
\n\nNone of that is optional, and all of it is invisible in a demo.
\n\nThe checkout is perhaps a fifth of it. The subscription stack is 572 lines, 225 of them the\nwebhook alone, against 864 lines of tests running 80 examples. The tests outweigh the code,\nwhich is the correct ratio for money.
\n\nWhat the webhook has to survive:
\n\nThe gate that actually checks all of this before someone uses a paid feature is 21 lines. That\nratio is the whole point: the enforcement is trivial, and the bookkeeping behind it is not. There is\nmore on why in how to charge without building billing.
\n\nThis is the smallest area on the list and the most expensive to get wrong: 275 lines, of which\nonly 64 are permission policy, plus 176 lines of tests.
\n\nIt is cheap because the decision is made once, at the schema, and then followed everywhere. It is\nexpensive because there is no second chance. The test that matters asserts that another account's\nrecord returns a 404, and it is worth more than the rest of the area combined. The full argument is\nin how to keep one customer from seeing another's data.
\n\nEmail is 120 lines, about ten of them the production mail settings, and there is no library. But\nthe days go to DNS records and to finding out a week later that your mail lands in spam because one\nrecord was missing. That work shows up in no line count at all, which is exactly why estimates miss\nit.
\n\nBackground jobs are 145 lines including configuration, with 104 lines of tests. No Redis and\nno extra service to run or pay for, because the queue lives in the database you already have. This\nis the one area where the honest answer is that it simply got much easier.
\n\n395 lines against 383 lines of tests running 36 examples. It is not one thing. It is six\nrate limits, an enforced content policy, request filtering, and the export and deletion routes the\nlaw expects you to have.
\n\nThe content policy deserves a warning. It is enforced rather than reporting, so a missing allowance\nbreaks a real flow silently: no error, no failed request, just a button that does nothing. Ten\nof those 36 examples exist only to pin that down.
\n\n802 lines of native code and 743 lines on the server, plus 525 lines of tests running 46\nexamples.
\n\nThe shells themselves are small. The cost is that both stores require their own purchase system for\ndigital goods, so you now have a second payment path with its own receipts and notifications, and\nboth paths have to arrive at one answer about who is subscribed. See getting your app into the app\nstores.
\n\n1,552 lines, 118 examples. It is the biggest single area in this repository, and it is the\none nobody puts in an estimate at all.
\n\nThat is the blog, the feeds, the sitemap, the structured data, the machine-readable files AI\nassistants read, and generated share cards. None of it is hard. There is simply a lot of it, and\nnone of it exists until you write it.
\n\n| Area | \nCode | \nTests | \nRealistic days | \n
|---|---|---|---|
| Sign-in | \n705 | \n377 | \n5 to 10 | \n
| Payments | \n572 | \n864 | \n5 to 10 | \n
| Keeping customers separate | \n275 | \n176 | \n3 to 6 | \n
| 120 | \n47 | \n2 to 4 | \n|
| Background jobs | \n145 | \n104 | \n1 to 3 | \n
| Hardening | \n395 | \n383 | \n3 to 5 | \n
| Deployment and CI | \n686 | \nn/a | \n2 to 5 | \n
| Core subtotal | \n2,898 | \n1,951 | \n21 to 43 | \n
| Mobile shells and in-app purchase | \n1,545 | \n525 | \n8 to 15 | \n
| Blog, SEO, and share cards | \n1,552 | \n1,005 | \n5 to 10 | \n
| Total | \n5,995 | \n3,481 | \n34 to 68 | \n
Repository-wide: 5,949 lines of application code, 3,595 lines of tests, 327 examples, 12\nmigrations, 50 routes. The two totals are close but not identical: the table adds native and\nconfiguration code that lives outside the application directory, and leaves out application code\nbelonging to none of these areas.
\n\nDeployment is the strange row. It contains no application code at all. It is 686 lines of\nconfiguration, and it still takes most of a week the first time.
\n\nEvery feature on that list has two versions.
\n\nThe demo version works. Sign-in signs you in, the checkout charges a card, the email sends. That\nversion genuinely is an afternoon, and it is the version people picture when they give a number.
\n\nThe done version is the bulleted lists above: expiry, replay, throttling, duplicate webhooks,\nrefunds, the silent policy failure, the second payment path. Not one of those is optional once real\npeople are using the thing, and none is visible until they are.
\n\nThe gap between the two versions is the estimate error. It is not a fudge factor, it is a specific\nlist, and it is roughly the same list in every product anyone builds. A coding agent compresses that\nlist meaningfully. It does not shorten it. That is the argument in what your coding agent should\nnever build from scratch.
\n\nThe tests. 3,595 lines against 5,949 lines of application code: six lines of test for every ten\nof application. If an estimate did not include that, it was not an estimate for finished work. It\nwas an estimate for the demo version.
\n\nThe money side of the same question is in what it actually costs to start an\napp, and the full inventory of what is already built is in\neverything you get on day one.
\n","date_published":"2026-08-18T00:00:00+00:00","date_modified":"2026-08-18T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["basics","getting started"]},{"id":"https://shiponeshot.com/blog/building-in-cursor","url":"https://shiponeshot.com/blog/building-in-cursor","title":"What is it like to build an app in Cursor?","summary":"Cursor puts the agent in your editor, with multi-file edits and a diff for everything. Here is how that changes the loop, and what to have set up first.","content_html":"What is it like to build in Cursor when every change is a diff?
\n\nIt is the tightest of the agent loops, because you never leave the editor and you see every change\nin place before you accept it. The tradeoff is that the tight loop encourages small steps, which is\nexcellent for editing a feature and less suited to building a whole one in a pass. The setup that\nmakes it work is the same as everywhere else: a codebase worth reading, and something to run.
\n\nTwo things, and they pull in opposite directions.
\n\nThe feedback is immediate. You see the change against the code around it, in the file you already\nhave open, with your own eyes on the surrounding context. This catches a whole class of \"technically\ncorrect, wrong for this file\" problems that are invisible in a terminal diff.
\n\nThe unit of work gets smaller. Because accepting is one keystroke, the loop pulls toward many\nsmall edits rather than one complete change. That is great for refining and genuinely worse for\n\"build me this feature end to end\", where you want the model, the policy, the controller, the screens,\nand the tests to arrive as one coherent set.
\n\nThe practical answer is to use the wider, multi-file mode for the first pass of a feature and the\ninline loop for everything after.
\n\nA guide file. Cursor will read the files you have open and the files it decides are relevant. A\nshort document stating the non-negotiable rules is the thing that keeps a small edit from quietly\nbreaking a convention that is enforced three directories away.
\n\nA worked example. The single most useful thing you can do is open the existing example of the\nthing you are building in another tab. Context that is already on screen is context it does not have\nto go looking for.
\n\nOne command that verifies. In this codebase that is bin/check. Small edits accumulate, and the\nrisk of the tight loop is that twelve individually reasonable changes add up to something that does\nnot pass.
The first pass, in the multi-file mode:
\nAdd a Bookmarks resource following the same shape as the example slice:\nmodel, policy, controller, views, routes, and specs.\nNaming the shape matters more than describing it. \"Following the same shape as the example slice\"\npoints at a file that already exists, which is far more precise than any description you could type.
\n\nWhat comes back should touch the model, the migration, the permission policy, the controller, the\nscreens, the route, and the tests. Read the migration and the policy properly. Skim the rest.
\n\nThen the tight loop takes over: adjust the empty state, fix the copy, tighten a validation, add the\none test you actually care about. This is where being in the editor pays.
\n\nLook at what the diff touched, not just what it says. The change summary is a description of\nintent. The file list is a description of blast radius. When those disagree, believe the file list.
\n\nRun the checks before you accept a run of edits, not after ten of them. The tight loop makes it\neasy to get twelve edits deep before running anything, and then the failure could be from any of\nthem. Verifying often makes each failure cheap to locate.
\n\nContext you did not intend. Having the wrong file open can steer a change. If a suggestion is\noddly shaped, check what is in your tabs before blaming the model.
\n\nAccepting is frictionless, which is the point and the problem. One keystroke to accept means it\nis genuinely easy to accept something you did not read. The files where this matters are the\nmigration and the permission policy, always. Slow down for those two and move fast everywhere else.
\n\nSmall steps hide structural drift. Twelve good local edits can arrive at a structure nobody would\nhave chosen deliberately. Every so often, step back and read the whole feature as one thing.
\n\nThe four categories where generated code is plausibly wrong\nare no more visible in an editor diff than in a terminal one. Sign-in, payments, email\ndeliverability, and customer data separation are best solved by already having them, tested, before\nthe first prompt.
\n\nThe same loop with other agents: Claude Code,\nCodex, Hermes, and\nOpenClaw.
\n","date_published":"2026-08-14T00:00:00+00:00","date_modified":"2026-08-14T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","cursor","walkthrough"]},{"id":"https://shiponeshot.com/blog/building-with-openclaw","url":"https://shiponeshot.com/blog/building-with-openclaw","title":"What is it like to build with a self-hosted agent?","summary":"Your own agent, your own model, driven from the chat apps you already use. Here is what that changes about building, and the two things to get right first.","content_html":"What is it like to build with a self-hosted agent like OpenClaw?
\n\nTwo things are genuinely different, and everything else is the same as any other agent. First, you\nchoose the model, which means the quality and the cost of a session are yours to tune rather than\nsomeone else's product decision. Second, you drive it from wherever you already talk, so the barrier\nto asking is a message rather than a terminal. Both of those are real advantages, and both of them\nhave a matching failure mode worth planning for.
\n\nSelf-hosting means the agent runs on your infrastructure with your model of choice and your\nextensions. Practically, that buys three things:
\n\nThe honest version of \"you choose the model\" is \"you can choose badly\". A weaker model on a\nplumbing-heavy task produces exactly the plausible-looking wrongness that is hardest to\ncatch: a webhook that does not verify signatures, a query\nmissing its account filter.
\n\nThere are two defenses, and you want both.
\n\nDo not put the risky work in scope. If sign-in, payments, email, and customer data separation\nalready exist and are tested, then no model choice you make can get them wrong, because they are not\nbeing written. This is the strongest available mitigation and it is structural rather than\nbehavioral.
\n\nMake verification non-optional. One command that runs the tests, the linter, a security scan, a\ndependency audit, and a secret scan, and a rule that nothing is done until it exits clean. A weaker\nmodel with a strict check is far safer than a stronger model with no check.
\n\nKicking off work from a message thread genuinely changes what gets done, because it changes what gets\nstarted. The ideas that would have waited for you to sit down often just happen.
\nadd a \"share\" button to bookmarks that copies a public link\nThat is a whole request, typed on a phone.
\n\nThe same convenience that gets more done produces the vaguest prompts you will ever write. The\nexample above does not say whether a shared link should work for signed-out visitors, whether it\nshould expire, or whether the owner can revoke it. Those are three product decisions, and the agent\nwill make all three for you.
\n\nTwo habits fix most of it:
\n\nIndependent of which model you point at it, the agent needs the same three things:
\n\nSilent capability drops. Change the model and the character of the output changes without any\nannouncement. If a session feels off, check what it is running before debugging the prompt.
\n\nExtensions that bypass the checks. The flexibility that makes self-hosting good also makes it\npossible to build a workflow that skips verification. Whatever else your setup does, make the check\nstep the one thing that cannot be routed around.
\n\nNo paper trail. Work started from a chat thread can land with no review. Decide where changes get\nreviewed, and keep that place, even when the request came from a message.
\n\nSelf-hosting moves the quality and cost dials into your hands. That is worth having, and it means the\nstructural safeguards matter more than they do elsewhere: a base where the dangerous parts are\nalready built and tested, a written set of conventions, and a check that cannot be skipped.
\n\nGet those three right and the model you pick becomes a tuning decision rather than a risk. That is\nmost of what a starter kit is for.
\n\nThe same loop with other agents: Claude Code,\nCodex, Cursor, and\nHermes.
\n","date_published":"2026-08-13T00:00:00+00:00","date_modified":"2026-08-13T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","openclaw","walkthrough"]},{"id":"https://shiponeshot.com/blog/building-with-codex","url":"https://shiponeshot.com/blog/building-with-codex","title":"What does building with Codex actually look like?","summary":"Codex proposes multi-file changes and waits for approval. Here is how that loop works on a codebase with clear conventions, and what to review first.","content_html":"What does building with Codex look like when you review every diff?
\n\nIt looks like a proposal, not a fait accompli. You describe the change, Codex reads the codebase and\ncomes back with a multi-file diff, and nothing happens until you approve it. On a codebase with clear\nconventions the proposal usually lands close enough to accept with one or two adjustments. On a\ncodebase without them, you spend the review arguing about structure instead of substance.
\n\nThe propose-then-approve loop is the whole character of working this way, and it rewards preparation\ndifferently from an agent that just runs.
\n\nWhen an agent executes directly, a wrong structural choice shows up as a failing test. When an agent\nproposes, a wrong structural choice shows up as a diff you have to evaluate, and evaluating structure\nis much slower than evaluating behavior.
\n\nSo the highest-value thing you can do before the first prompt is make the right structure obvious:
\n\nAGENTS.md) stating the rules that are not negotiable.With those, the proposal arrives already shaped like your codebase, and your review is about the\nproduct decisions rather than the file layout.
\n\nAdd subscriptions to the billing flow for a new \"team\" tier.\nFollow the conventions in AGENTS.md.\nThe second line does more work than it looks like. It tells Codex that there is a document with\nopinions in it, which changes what it reads before proposing.
\n\nA diff spanning six files is easy to skim and easy to skim badly. There is an order that catches the\nmost problems for the least reading, and it is not top to bottom.
\n\nFirst, the migration. Schema changes are the most expensive to reverse once there is data.\nCheck the column types, the null constraints, the indexes, and above all the foreign key to the\naccount. If a table holding customer data has no account reference, stop there; nothing downstream\ncan be correct.
\n\nSecond, the permission policy. This is where a subtle mistake is invisible and serious. The\nquestion to ask is not \"does this allow the right people\" but \"what does it do when it is unsure\".\nDeny by default, and every query filtered to the current account.
\n\nThird, the query in the controller. Look for lookups that go through the model directly instead\nof through the current account. Thing.find(params[:id]) and Current.account.things.find(params[:id])\nlook almost identical and differ by whether a customer can read another customer's record by\nguessing a number.
Then everything else. Screens, copy, and formatting are cheap to change later and rarely\ndangerous.
\n\nConsistency across files. A change that touches a model, a policy, a controller, screens, and\ntests is exactly the kind of thing where a human forgets the fifth file. A proposal that arrives as a\ncomplete set is easier to reason about than five separate edits.
\n\nMatching existing style. It reads the surrounding code and writes in it. On a codebase that is\ninternally consistent this is close to free; on one that is not, it will faithfully reproduce whatever\nit happened to read first.
\n\nNot surprising you. The thing people actually like about this loop is that nothing runs until you\nsay so. That is worth real money on a production codebase.
\n\nVague requests produce large diffs. \"Improve the billing flow\" is an invitation to touch fifteen\nfiles. Ask for one change at a time; the review cost of a proposal grows faster than its size.
\n\nIt cannot tell a convention from an accident. If your codebase does something inconsistently in\ntwo places, the proposal picks one, and it may pick the one you were planning to remove. This is not\na failure of the tool, it is a failure of the codebase to have an opinion.
\n\nApproval is not verification. A diff that reads correctly can still fail. Run the checks after\napproving, every time. The propose-then-approve loop makes it tempting to treat your read as the\ncheck, and your read is not the check.
\n\nFix the example, not the copies.
\n\nEvery feature Codex proposes will resemble the nearest existing feature. That makes your worked\nexample the highest-leverage file in the repository: improve it once and every future proposal\nimproves. Let a flaw sit in it and you will review the same flaw ten times, approving it each time\nbecause it matches what is already there.
\n\nThe four things where generated code looks right and is\nnot are exactly the four things a diff review is worst at\ncatching, because they are correct-looking by construction. If sign-in, payments, email\ndeliverability, and customer data separation already exist and are tested in your codebase, they are\nnot in the diff, and the review stays about your product.
\n\nThat is most of the argument in what a starter kit is.
\n\nThe same loop with other agents: Claude Code,\nCursor, Hermes, and\nOpenClaw.
\n","date_published":"2026-08-12T00:00:00+00:00","date_modified":"2026-08-12T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","codex","walkthrough"]},{"id":"https://shiponeshot.com/blog/keeping-customer-data-separate","url":"https://shiponeshot.com/blog/keeping-customer-data-separate","title":"How do you keep one customer from seeing another's data?","summary":"One missing filter is all it takes, and it has no symptoms in development. The structure that makes correct scoping the default, not something you remember.","content_html":"How do you keep one customer from seeing another customer's data?
\n\nPick one boundary, put it on every record, and make every query go through it by default rather than\nby memory. The failure is always the same: one query somewhere that forgot to filter. It has no\nsymptoms in development, no failing test unless you wrote one specifically, and no error in\nproduction. Somebody just sees somebody else's data.
\n\nThe only reliable defense is structural. Here is the structure.
\n\nBefore any code, answer one question: what owns a piece of customer data?
\n\nUsually it is an account or workspace rather than a user, because eventually somebody wants to invite\na colleague, and if your data belongs to individual users you will be rewriting everything to fix it.
\n\nChoosing account-as-boundary on day one costs nothing even if you never ship teams. Choosing\nuser-as-boundary and changing your mind costs a migration of every table you have.
\n\nSo: an account is the boundary. A user belongs to an account. Every piece of customer data\nbelongs to an account.
\n\nWrite these down where your team and your coding agent will read them, because they only work if they\nare followed everywhere.
\n\nNot most. Every model holding customer data, with a non-null constraint and a foreign key at the\ndatabase level.
\n\nThe database constraint matters. It means a row without an owner cannot exist, so \"which account does\nthis belong to?\" always has an answer. A nullable column invites a code path that forgets to set it,\nand then you have orphan records that no scoped query will ever return and nobody will ever find.
\n\nThis is the load-bearing rule. Compare:
\nThing.find(params[:id]) # wrong: any id, any account\nCurrent.account.things.find(params[:id]) # right: only this account's ids\nThose two lines look nearly identical, and they differ by whether a customer can read another\ncustomer's record by changing a number in the address bar. In the second version an id belonging to\nsomeone else simply is not found, so it returns a 404, which is also the correct thing to tell them:\nconfirming that a record exists but is not theirs is itself a small leak.
\n\nThe reason to make it a rule rather than a habit is that habits fail once and rules fail visibly. If\nevery query in your codebase starts from Current.account, then one that does not stands out in\nreview.
Every action asks a policy object whether it is allowed, and the base policy says no. A new action\nwith no rule written is forbidden, not permitted.
\n\nThis matters because the common failure is forgetting to add a check, not writing a wrong one. Deny\nby default turns forgetting into a visible error rather than an open door.
\n\nThe default scope on those policies should filter to the current account too, so listing records is\nscoped by the same mechanism as fetching one.
\n\nEvery resource you add ships with this test:
\n\n\n\n\nA signed-in user requests a record belonging to a different account. The response is a 404.
\n
That is it. It is three lines and it is the difference between believing your scoping works and\nknowing it.
\n\nWrite it for the first resource, then copy it for every one after. The value is not in the individual\ntest, it is that the test is part of the shape of a resource, so an agent copying the pattern copies\nthe test too.
\n\nWorth being explicit, because it explains why careful people ship this bug.
\n\nOn your laptop you have one account. Everything you can see belongs to you. An unscoped query returns\nexactly the same result as a scoped one, on every screen, every time. The app is marginally faster\nwithout the filter. Nothing is red.
\n\nThe bug becomes reachable the moment you have two customers, and it becomes visible the moment two\ncustomers' ids collide in someone's address bar. Between those two moments, it is present and silent.
\n\nThis is why the category of failure matters more than the\nindividual bug: you cannot find it by testing normally, because testing normally is what hides it.
\n\nEven with the rules, a few spots get forgotten. Check these specifically:
\n\nTwo things, and they are the reason to do it on day one rather than when it hurts.
\n\nTeams become easy. If data already belongs to accounts and users already belong to accounts, then\ninviting a second person to an account is a small feature rather than a rewrite.
\n\nDeletion becomes possible. \"Delete everything belonging to this customer\" is a real obligation in\nseveral jurisdictions. If every record has an account reference, that is a query. If ownership is\nimplied by relationships that vary per table, it is a project, and one you cannot be confident you\nfinished.
\n\nGet the structure right and correct scoping becomes the path of least resistance, which is the only\nversion of this that survives contact with a deadline. It is also the first item on the checklist\nthat makes an app safe to launch.
\n","date_published":"2026-08-10T00:00:00+00:00","date_modified":"2026-08-10T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["security","how-to"]},{"id":"https://shiponeshot.com/blog/start-a-blog-and-get-found","url":"https://shiponeshot.com/blog/start-a-blog-and-get-found","title":"How do you start a blog on your app and actually get found?","summary":"Files beat a database, and the biggest mistake is blocking the crawlers that actually send you traffic. The whole setup, including what we built for this site.","content_html":"How do you start a blog on your app and actually get found?
\n\nStore posts as files rather than in a database, publish the machine-readable surfaces that search\nengines and AI assistants look for, and make sure you are not accidentally blocking the crawlers that\nsend you traffic. The last one is the most common own goal, and the one nobody notices, because\nnothing about it produces an error.
\n\nThis post is the blog you are reading. Here is how it is built.
\n\nThe instinct is a posts table with an admin interface. Resist it.
\n\nA database-backed blog needs authentication, permissions, an editor, image uploads, a draft workflow,\nand a preview mode. That is a real product, and it is not the one you are building.
\n\nFiles skip all of it. A post is a markdown file with a few lines of metadata at the top. The filename\nis the address. You already have a text editor, and your writing gets reviewed and versioned exactly\nlike your code.
\n\nThe tradeoff is honest: publishing requires a deploy, and non-technical colleagues cannot post\nwithout one. For a product blog written by the people who build the product, that is a fine trade,\nand it is the right default until it stops being.
\n\nThis is the part worth automating once, because doing it by hand per post is how it gets skipped:
\n\nNone of this is per-post work if you generate it from the post's own metadata.
\n\nUsually a static file with a stale sitemap line. Serve it from the application instead and it can\nknow its own address, stay correct across environments, and survive a rebrand.
\n\nA convention that is quickly becoming worth having: a markdown index of your site at /llms.txt,\nlisting your pages and posts with a one-line description each, so an assistant can understand what\nyou have in one fetch rather than by crawling. Pair it with a full-text version that inlines\neverything.
Serve the raw source of each post at the same address with a .md extension, and link it from the\npage. A crawler or a tool that wants your text does not have to parse your HTML to get it.
AI crawlers are not one thing. They come in three kinds, and they behave completely differently:
\n\n| Kind | \nWhat it does | \nSends you traffic? | \n
|---|---|---|
| Training | \nBuilds model weights | \nNo | \n
| Search index | \nBuilds the assistant's retrieval index | \nYes, as citations | \n
| Live fetch | \nFetches on demand when someone asks | \nYes, directly | \n
Most sites that decide to \"block AI\" write rules aimed at the training crawlers and take out the\nfetchers by accident. The result is that they disappear from AI answers entirely, while every other\nmetric looks completely normal.
\n\nIf you want traffic from assistants, the search-index and live-fetch categories are the ones to\nwelcome, explicitly, by name.
\n\nTwo things people get wrong here. Google-Extended and Applebot-Extended are not crawlers;\nthey are training opt-out tokens, and disallowing them does not remove you from AI Overviews. And a\ncrawler cannot be blocked by robots.txt alone if something in front of your app is already refusing\nit.
This is the part worth checking today, whatever else you take from this post. Any of these can hide\nyour site with no error, no log line, and no symptom:
\n\nOne command tests all three at once:
\ncurl -sI -A \"OAI-SearchBot\" https://yourdomain.com/blog | head -1\nIf that is not a 200, nothing else on this page matters.
\n\nThe structural work above gets you readable. This gets you cited.
\n\nAn assistant lifts a passage from your page and shows it with no surrounding context. So:
\n\nThe last piece of advice is the one that matters most: write about the thing where you are genuinely\nthe best available source. Anyone can restate a popular tutorial, and the results already have forty\nof those. Nobody else can explain what your product actually does, what it costs, or what you learned\nbuilding it.
\n\nThat is the post worth writing first.
\n","date_published":"2026-08-08T00:00:00+00:00","date_modified":"2026-08-08T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["writing","seo","how-to"]},{"id":"https://shiponeshot.com/blog/building-with-claude-code","url":"https://shiponeshot.com/blog/building-with-claude-code","title":"What does building with Claude Code actually look like?","summary":"A walkthrough of the real loop: what you type, what it reads, what it writes, and where you step in. One prompt and one review for a tested feature.","content_html":"What does building a paid feature with Claude Code actually look like?
\n\nIt looks like one clear instruction, a few minutes of the agent reading before it writes anything, a\ndiff covering six or seven files, a test run it does itself, and one review pass from you. The\nfeature that comes back is account-scoped, permission-checked, paywalled, and tested, because those\nare the conventions it found in the codebase rather than things you asked for.
\n\nHere is the loop in detail, and the parts where it goes wrong.
\n\nClaude Code works in your terminal. It reads files, writes changes, and runs commands, which means it\ncan check its own work. That last capability is the one that changes the character of a session, and\nit only pays off if there is something worth running.
\n\nSo before anything else, the codebase needs two things:
\n\nCLAUDE.md in the project root, telling it the one right way to\ndo each thing here.bin/check in this case, which runs the tests, the linter, a static\nsecurity scan, a dependency audit, and a secret scan in one command.Without the first, it guesses at your conventions. Without the second, \"done\" is something it asserts\nrather than something it verifies.
\n\nHere is the entire prompt for a real feature:
\nAdd a paid Bookmarks feature. A bookmark has a url, a title, and an optional note.\nUse the crud-with-billing skill.\nThat is it. Note what is not in there: no mention of accounts, no mention of permissions, no mention\nof tests, no mention of the design system. All of that is already written down, and repeating it in\nthe prompt is how you end up with a prompt that is longer than the feature.
\n\nThe first thing that happens is reading, and it is worth watching rather than skipping.
\n\nIt opens CLAUDE.md and finds the rule that governs everything: every model belongs to an account,\nevery query goes through the current account, every controller checks permissions. Then it opens the\nworked example that already exists in the codebase, the one deliberately left there to be copied, and\nreads the whole vertical slice: the model, the permission policy, the controller, the screens, and\nthe tests.
By the time it writes its first line it has a template. It is not inventing a structure, it is\nfollowing one.
\n\nWhat comes back is about seven files:
\n\nThat last test is the one people forget when they write this by hand, and it is the difference\nbetween a feature and an incident.
\n\nThree places, and none of them is the code style.
\n\nThe data model. The agent will make reasonable choices and some of them will be wrong for your\nproduct. Should a bookmark belong to a user or to the whole account? Should the url be unique per\naccount? These are product decisions wearing schema clothing, and they are much cheaper to fix now\nthan after there is data.
\n\nWhether it should be paid at all. You said paid, so it made it paid. Whether that is right is not\nsomething it can know.
\n\nThe empty state and the copy. It will write something sensible and generic. Sensible and generic\nis exactly what your product should not sound like.
\n\nBeing honest about the failure modes, because they are consistent.
\n\nIt over-builds when the request is vague. \"Add bookmarks\" with no further detail produces\nbookmarks with tags, folders, search, and bulk import. Every one of those is a thing you now own.\nBeing specific about what you do not want is worth more than being specific about what you do.
\n\nIt follows a bad example faithfully. The flip side of pattern-matching your codebase is that it\nwill copy your mistakes with the same enthusiasm as your conventions. If the worked example has a\nflaw, every feature built after it inherits the flaw. Fix the example, not the copies.
\n\nIt declares victory on a partial run. If the test command is slow or noisy it will sometimes\nsummarize rather than actually check. The fix is a single command that exits non-zero on any failure,\nand a guide file that names it as the definition of done.
\n\nThe tests. Not that the agent writes them, but that it uses them.
\n\nA run where the suite goes red partway through does not come back to you broken. It reads the\nfailure, fixes it, and runs again. You see the finished state. This is the practical difference\nbetween an agent that can execute commands and one that only writes text, and it is why the setup\nwork at the top of this post is worth doing before the first feature rather than after the third.
\n\nYou still have to review. The diff is small and it is entirely about your feature, which makes the\nreview genuinely quick, but \"quick\" is not \"unnecessary\". Read the migration and the permission\npolicy properly, every time. Those are the two files where a mistake is expensive and silent.
\n\nAnd it does not remove the need to know what you are building. The agent is very fast at producing\nthe thing you described. It has no opinion about whether the thing was worth describing.
\n\nThe shape above works because the codebase was arranged for it: a guide file, a worked example, one\nverification command, and the plumbing already built and tested. That is what a starter kit\nis, and it is why the first run otherwise disappears into\nplumbing.
\n\nThe same loop works with Codex, Cursor,\nHermes, and OpenClaw, with differences\nworth knowing about in each.
\n","date_published":"2026-08-07T00:00:00+00:00","date_modified":"2026-08-07T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","claude code","walkthrough"]},{"id":"https://shiponeshot.com/blog/email-that-arrives","url":"https://shiponeshot.com/blog/email-that-arrives","title":"Why does your app's email go to spam, and how do you fix it?","summary":"Almost always missing DNS records, not your code. What SPF, DKIM, and DMARC do, the order to set them up, and the From-address mistake that undoes all three.","content_html":"Why does your app's email go to spam, and how do you fix it?
\n\nBecause you are missing DNS records, not because your code is wrong. Three records decide whether\nyour mail is trusted: SPF says which servers may send for your domain, DKIM signs each\nmessage cryptographically, and DMARC tells receiving servers what to do when the first two fail.\nPublish all three, make sure your From address is on the domain you signed with, and the problem\nusually disappears within a day or two.
\n\nThe code is two lines. This is the other 95% of the work.
\n\nTwo things changed.
\n\nLarge mailbox providers tightened their requirements, and messages from domains with no\nauthentication now get treated with more suspicion than they used to. And if your product uses\npasswordless sign-in, your email is not marketing, it is your\nfront door. Mail in spam means nobody can log in, and there is no error anywhere to tell you.
\n\nA DNS record listing the servers allowed to send mail for your domain. A receiver checks the sending\nserver against that list.
\n\nYour email provider tells you what to publish. It usually looks like:
\nv=spf1 include:_spf.yourprovider.com ~all\nTwo things people get wrong:
\n\ninclude: into it.include: counts. Stack up\nenough providers and it silently starts failing.Your provider signs outgoing mail with a private key. You publish the matching public key in DNS.\nThe receiver verifies the signature and knows the message was not altered and really came from you.
\n\nYour provider generates this and gives you the record to publish. There is not much to get wrong\nbeyond pasting it correctly, and it is the strongest of the three signals.
\n\nThis is the one people skip, because mail appears to work without it, and it is increasingly the one\nthat decides whether you are trusted.
\n\nDMARC does two jobs: it tells receivers your policy for failures, and it makes them check\nalignment, which is the part that actually catches spoofing.
\n\nStart here, on day one:
\nv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com\np=none means \"do not change anything, just send me reports\". It is safe to publish immediately and\nit starts giving you data about who is sending as you.
Once the reports look clean, tighten it:
\nv=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com\nThen eventually p=reject. Do not start at reject. If something legitimate is misconfigured, you\nwill stop your own mail, and the first thing you will notice is customers unable to sign in.
Here is the one that catches people who did everything else right.
\n\nYou verify yourdomain.com with your email provider. DKIM signs as yourdomain.com. Then you set\nyour From address to hello@somethingelse.com, perhaps because that is where you read replies.
Now DKIM signs one domain while the From header claims another. Alignment fails, DMARC fails, and\nyour carefully configured setup is worse than useless, because you are now producing exactly the\nsignature-mismatch pattern that spoofing filters exist to catch.
\n\nThe rule: the From address must be on the domain you authenticated.
\n\nIf you want replies somewhere else, forward the address at your provider. Do not solve it with a\nReply-To on a different domain, and do not solve it by changing the From.
\n\np=none with a reporting address. Do this on day one; it costs nothing and\nstarts collecting evidence.p=quarantine, then later to p=reject.Almost trivial by comparison, but three things are worth getting right.
\n\nSend both HTML and plain text. A message with no plain text alternative looks worse to filters,\nand some clients genuinely prefer it.
\n\nSend outside the web request. A slow mail provider should never slow down a page. Queue the\nmessage and deliver it in a background job. This is\nalso what makes retries possible when the provider has a bad minute.
\n\nDo not send real mail in development. Every developer has sent a test message to a real customer.\nUse a local preview that opens the message in a browser instead of delivering it, so nothing can\nescape from a laptop.
\n\nWorth knowing before it hurts.
\n\nYour sign-in codes and receipts are transactional. Your newsletter is marketing. If they share a\nsending domain and enough people mark the newsletter as spam, the reputation damage takes your\nsign-in codes down with it.
\n\nThe usual fix is a subdomain for marketing, keeping the reputation of your transactional mail\nseparate from anything anyone might complain about.
\n\np=none, tightened once the reports are clean.This is one of the four things worth not building\nyourself, and it is the clearest case of all four: no amount\nof better code fixes it, because the code was never the problem.
\n","date_published":"2026-08-05T00:00:00+00:00","date_modified":"2026-08-05T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["email","how-to"]},{"id":"https://shiponeshot.com/blog/your-app-in-the-app-stores","url":"https://shiponeshot.com/blog/your-app-in-the-app-stores","title":"How do you get your app into the App Store and Play Store?","summary":"Wrap it in a native shell that loads your existing screens. What it costs, what the stores require, and the in-app purchase rule that decides your economics.","content_html":"How do you get your web app into the App Store and Play Store?
\n\nWrap it in a thin native shell that loads your existing web screens, add native navigation so it does\nnot feel like a browser, and wire up in-app purchases because both stores require them for digital\ngoods. You maintain one codebase and ship to three places. The costs are $99 per year for Apple,\n$25 once for Google, and up to 30% of every purchase made inside the app, which is usually\nthe number that decides whether this is worth doing at all.
\n\nYou do not rebuild your product twice. You build a small native application whose main job is to\ndisplay your web screens, plus the parts that genuinely have to be native.
\n\nThat is not the same as shipping a bare browser window. A shell like this gives you:
\n\nThat last point is worth dwelling on. Anything driven by your server changes when you deploy.\nAnything compiled into the app waits for review. Keeping as much as possible on the server side is\nthe difference between a two-hour fix and a two-day one.
\n\nBe realistic about the boundary:
\n\nEverything else can be a web screen, and should be, because it is one implementation instead of\nthree.
\n\nIf you sell digital goods or subscriptions that are used inside your app, both stores require you to\nsell them through their purchase system, and both take a cut of up to 30%, reduced for smaller\ndevelopers under their respective programs.
\n\nYou cannot avoid this by linking out to your own checkout from inside the app. That gets rejected,\nand the rules around what you may and may not say about outside payment options have shifted\nrepeatedly. Read the current guidelines rather than a blog post, including this one.
\n\nThe strategic consequence: your web checkout and your in-app checkout are different businesses\nwith different margins. Many products deliberately steer signups to the web, where they keep the full\namount, and treat in-app purchase as a convenience for people who found them in the store.
\n\nYou now have two ways for someone to pay, and they arrive as completely different things: a payment\nprovider's webhook on one side, and a store receipt on the other.
\n\nThe trap is building two parallel systems that each track what a customer has paid for, and then\ndiscovering they disagree. Somebody subscribes on the web and opens the app, which does not know. Or\nsubscribes in the app and uses the web, which does not know.
\n\nThe fix is to make entitlement a single concept. One record per account answering \"is this\naccount currently allowed to use the paid feature, and until when\". Both payment paths write to it.\nEverything else reads it and does not care where the money came from.
\n\nGet that right and adding a third payment route later is a small job. Get it wrong and every new\nroute multiplies the states you have to reconcile.
\n\nBoth stores review submissions. The rejections that come up repeatedly:
\n\nMost of these are cheap if you know them in advance and expensive if you find them at submission,\nbecause each round trip through review costs days.
\n\nFor a product whose web app already exists and works:
\n\n| Work | \nTime | \n
|---|---|
| Shell running, loading your screens | \n1 to 2 days | \n
| Native navigation rules | \n1 to 3 days | \n
| In-app purchase, both platforms | \n3 to 7 days | \n
| Icons, launch screens, store listings, screenshots | \n2 to 3 days | \n
| Review, first submission | \n1 to 7 days, plus rework | \n
Call it two to three weeks including the first rejection, which you should assume rather than hope\nagainst.
\n\nThe in-app purchase line is the one that surprises people. It is not just a payment button, it is\nreceipt validation, restoring purchases, renewals, and the notifications that tell your server when a\nsubscription changed state. It is the same source-of-truth problem as web\npayments, in a different shape.
\n\nThe honest answer is that it depends on where your customers look for you.
\n\nProbably yes if your product is used on a phone regularly, if being findable in a store matters\nto your audience, or if you need notifications or hardware access.
\n\nProbably not yet if your product is used at a desk, if your customers find you through search or\nword of mouth, or if you have not validated the web version. Two to three weeks plus 30% of in-app\nrevenue is a real price for a channel that may not be where your customers are.
\n\nIf you do go ahead, get the entitlement model right first. That single decision determines whether\nthe second payment route is a week of work or a permanent source of support tickets.
\n","date_published":"2026-08-04T00:00:00+00:00","date_modified":"2026-08-04T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["mobile","how-to"]},{"id":"https://shiponeshot.com/blog/agent-guide-file","url":"https://shiponeshot.com/blog/agent-guide-file","title":"How do you write a guide file your agent will follow?","summary":"Short, specific, and about decisions rather than description. What belongs in a guide file, what to leave out, and why most of them get ignored.","content_html":"How do you write a guide file your coding agent will actually follow?
\n\nKeep it under about 150 lines, make every line a decision rather than a description, and point at\nreal files instead of explaining them. The failure mode is not that agents ignore instructions, it is\nthat most guide files are documentation, and documentation tells you what exists rather than what to\ndo. A guide file is a map of choices: here is the one right way to do this thing, here is the file to\ncopy, here is the rule that must never be broken.
\n\nOpen a typical CLAUDE.md or AGENTS.md and it reads like a README: an overview of the project, a\nlist of directories, a description of the stack, some setup commands.
None of that changes a single decision. The agent can already see the directory structure. It can\nread the dependency file. Telling it \"we use a background job system\" is not information; telling it\n\"background work goes through the existing job class, never a thread, and here is the one to copy\"\nis.
\n\nThe test for every line: if the agent had not read this, would it have done something different?\nIf not, cut the line. A 600-line guide file where 40 lines matter performs worse than a 40-line one,\nbecause the signal is diluted and the important rules are somewhere in the middle.
\n\nEvery codebase has one or two invariants where a violation is serious and silent. Put them first, in\nplain language, with the consequence stated.
\n\nIn this codebase it is data separation:
\n\n\n\n\nEvery model gets an account reference. Every query is scoped to the current account. Every\ncontroller checks permissions. Break this rule and one customer sees another's data.
\n
That is short, it is unambiguous, and it names the cost. An agent reading it has no room to decide\nthat this particular query is an exception.
\n\nNot the options. The choice.
\n\nAn agent that finds three plausible ways to add a feature will pick one, and it will not be the same\none next time. Consistency across features is worth more than any individual choice being optimal, so\nmake the choice once and write it down.
\n\nThis is the highest-leverage thing in the whole document, and it is why a guide file can be short.
\n\nInstead of describing the shape of a feature over two pages, name the file that already has that\nshape:
\n\n\n\n\nThe canonical example is the example slice: read
\napp/models/project.rb,\napp/policies/project_policy.rb,app/controllers/projects_controller.rb, and its specs, then\ncopy that shape.
Code is more precise than prose about code, it does not drift out of date, and the agent is better at\nreading it than at reading your description of it.
\n\nOne command, and the statement that it must pass.
\n\n\n\n\nVerify your work:
\nbin/check. This is the definition of done. It must be green before you are\nfinished.
Without this an agent decides for itself when it has finished, and the only evidence available to it\nis that the code it wrote looks like code that works.
\n\nThe most valuable and most commonly missing section. Every mature codebase has a few landmines where\nthe failure produces no error at all: a policy that blocks something with no message, a check that\nreturns an empty result rather than raising, a configuration that has to be updated in two places.
\n\nAn agent cannot discover these by reading, because there is nothing to read. Write them down, with\nthe symptom:
\n\n\n\n\nThe content security policy is enforced and it fails silently. Sending a user to an external host\nmeans adding that host to the policy. Miss it and the button does nothing: no exception, no\nmessage, nothing in the network tab.
\n
That paragraph saves an hour of confused debugging every time it is read.
\n\nThe best guide files are grown, not drafted.
\n\nEvery time an agent does something you have to correct, ask whether it could have known. If it could\nhave, and the guide file did not say so, add a line. If it could not have, that is a codebase problem\nand the fix is in the code.
\n\nAfter a few weeks this converges on a document that is short, specific to your project, and mostly\ncomposed of things that were genuinely surprising once.
\n\nThat fits comfortably in 150 lines and does more than a document four times the length.
\n\nA guide file is only half of it. The other half is that the codebase has to actually be followable.
\n\nIf your project does the same thing three different ways, no document will fix that, because the\nagent reads the code too and the code disagrees with itself. Write the rule, then make the codebase\nmatch it. The document describes the grain; it cannot create one.
\n\nRelated: why the first agent run disappears into plumbing and how\nto brief an agent for one working feature.
\n","date_published":"2026-08-02T00:00:00+00:00","date_modified":"2026-08-02T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","craft"]},{"id":"https://shiponeshot.com/blog/briefing-your-agent","url":"https://shiponeshot.com/blog/briefing-your-agent","title":"How do you brief a coding agent to get one working feature?","summary":"Say what it is, say what it is not, name the example to copy. Three sentences beats three paragraphs, and over-specifying makes the result worse.","content_html":"How do you brief a coding agent to get one working feature?
\n\nThree sentences: what the thing is, what it is explicitly not, and which existing example to copy.\nEverything else should already live in the codebase, and if it does not, the fix is to put it there\nrather than to write a longer prompt. Long briefs feel thorough and mostly produce features with\nparts nobody wanted.
\n\nHere is a complete, real one:
\nAdd a Bookmarks feature: a url, a title, and an optional note.\nNo tags, no folders, no search yet.\nFollow the shape of the example slice, and put it behind the paywall.\nSentence one is the thing. Sentence two is the boundary. Sentence three points at a template and\nmakes the one product decision the agent cannot infer.
\n\nThat is enough to get back a model, a migration, permission rules, a controller, screens, routes, and\ntests, all consistent with everything else in the codebase.
\n\n\"No tags, no folders, no search yet\" is the highest-value line in that prompt, and it is the one\npeople never write.
\n\nGiven an under-specified request, an agent does not stop and ask. It fills the gap with reasonable\ndefaults, and reasonable defaults for \"bookmarks\" include tags, folders, search, import, and export,\nbecause that is what bookmarks usually have. Every one of those arrives as code you now own,\nmaintain, test, and eventually remove.
\n\nStating the boundary is cheaper than stating the contents. You can describe what you want in eight\nwords; describing everything you do not want would take a page. So name the two or three obvious\nextensions and rule them out explicitly.
\n\nThe instinct after a bad result is to write a longer prompt. It usually makes things worse, for three\nreasons.
\n\nIt competes with the codebase. If your guide file says one thing and your prompt implies another,\nyou have created a conflict, and which one wins is not predictable.
\n\nIt buries the important part. In a page of instructions, the one line that actually mattered gets\nthe same weight as the rest.
\n\nIt specifies the wrong layer. People over-specify implementation (\"use a join table with a\ncomposite index\") and under-specify product (\"should two people be able to bookmark the same thing\").\nThe implementation is the part the agent is good at. The product decisions are the part only you\nknow, and they are what the brief should spend its words on.
\n\nIf you find yourself typing the same instruction every time, that is a signal.
\n\n\"Make sure it is scoped to the account, add permission checks, write tests, use the existing design\nclasses\" should not be in a prompt. It should be in the guide file, and it should be visible in the\nworked example the agent copies. Then it happens whether you remember to ask or not, which is the\nentire point.
\n\nA prompt is for what is different about this feature. Everything that is true of every feature\nbelongs somewhere permanent.
\n\nFor anything you cannot state in three sentences, spend one round on a plan:
\nBefore writing code, tell me in five lines how you would add team invitations.\nFive lines is enough to reveal a misunderstanding and cheap enough that you will actually read it.\nCatching a wrong assumption here costs seconds; catching it in a finished diff costs a rebuild.
\n\nSkip this for small, well-bounded work. Use it whenever the feature touches something that already\nexists.
\n\nThe reviewing habit matters more than the prompting habit, and there is an order that catches the\nmost for the least reading:
\n\nIf your briefs keep getting longer, the problem is not your prompting.
\n\nA prompt that has to explain your conventions means your conventions are not written down. A prompt\nthat has to describe the shape of a feature means there is no example to point at. A prompt that has\nto say \"and make sure it works\" means there is no command that verifies.
\n\nFix those three and the briefs get shorter on their own. That is the argument in how to write a\nguide file your agent will actually follow, and it is why the first run\notherwise disappears into plumbing.
\n\nSay what it is. Say what it is not. Point at the example. Then read the migration and the permission\nrules properly, and skim the rest.
\n","date_published":"2026-08-01T00:00:00+00:00","date_modified":"2026-08-01T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","craft"]},{"id":"https://shiponeshot.com/blog/safe-to-launch-checklist","url":"https://shiponeshot.com/blog/safe-to-launch-checklist","title":"What makes an app safe to launch?","summary":"Twelve checks that separate a demo from something you can put in front of strangers, ordered by how much damage each one prevents.","content_html":"What makes an app safe to launch?
\n\nTwelve things, and they are not evenly important. The first four prevent a customer seeing another\ncustomer's data, someone using what they did not pay for, an account takeover, or a leaked secret.\nThe rest prevent smaller, recoverable problems. If you only have a day before launch, do the first\nfour properly and skip the rest rather than doing all twelve badly.
\n\nHere they are, in order of how much damage each one prevents.
\n\nThe worst thing that can happen. One missing filter and somebody reads somebody else's data.
\n\nCheck: pick five endpoints that load a record by id and confirm each looks it up through the\ncurrent account, not through the model directly. Then confirm you have a test that requesting\nanother account's record returns a 404.
\n\nThis has no symptoms in development, because you have one account and everything you can see is\nyours. Do not rely on having noticed it. The full version is in keeping every customer's data\nseparate.
\n\nHiding a link is not access control. If the only thing between an unpaid account and a paid feature\nis an unrendered button, the feature is free to anyone who types the address.
\n\nCheck: sign in with an account that has no subscription and request a paid endpoint directly. You\nshould be refused.
\n\nAn API key committed once is compromised forever, because it is in the history even after you delete\nit. This includes test keys, which are frequently attached to accounts that can do real things.
\n\nCheck: run an automated secret scanner over your entire history, not just the current files.\nEveryone does this eventually. Do it before strangers can read the code.
\n\nCodes and tokens are credentials. They need short expiry, a limited number of attempts, and rate\nlimits both per account and per network address, so nobody can request fifty sign-in codes for\nsomeone else's inbox.
\n\nCheck: request the same thing twenty times quickly and confirm you get refused.
\n\nSign-in, sign-up, password or code requests, checkout, and anything that sends email or costs you\nmoney per call. A blanket limit per address is a reasonable backstop.
\n\nOne caveat worth knowing: exclude the paths you want crawled. A blanket limit that also catches\nsearch engines and AI crawlers will hand them errors, and they read that as a reason to visit less\noften. That failure is completely invisible from inside the app.
\n\nNot report-only. Report-only tells you about problems and prevents none of them.
\n\nThe warning: an enforced policy fails silently. When it blocks something, the browser does not\nraise an error your app can see. The button just does nothing. So test the flows that leave your\nsite, especially checkout and social sign-in, with the policy on. Finding this in production is a\nmiserable afternoon.
\n\nAny endpoint that changes state based on an outside call must verify it came from who it claims.\nWithout this, your payment webhook is a public URL that grants subscriptions to anyone who finds it,\nwith no error anywhere. See charging for your app.
\n\nIn several jurisdictions people have a right to their data and a right to have it removed, on a\ndeadline. Beyond the legal question, \"delete my account\" is a request you will get in the first week.
\n\nCheck: actually run both, end to end, on a real account. Deletion in particular tends to fail on the\nrecords nobody remembered.
\n\nSPF, DKIM, and DMARC published, and your From address on the domain you signed with. If you use\npasswordless sign-in, this is not a deliverability concern, it is an availability concern: mail in\nspam means nobody can log in. See email that reaches the inbox.
\n\nA backup you have never restored is a hypothesis. Restore one into a scratch environment and confirm\nthe data is there. Do this once before launch and you will sleep better forever.
\n\nNot just log files on a server nobody opens. You want to find out about the exception from a\nnotification, not from the customer who hit it.
\n\nOne command tells you whether anything you depend on has a known vulnerability. Run it, and run it on\nevery change after.
\n\nThe checklist above is worth doing once. It is worth much more if it cannot rot.
\n\nMost of it can be automated: tests, a linter, a static security scan, a dependency audit, and a secret\nscan behind a single command that exits non-zero if anything fails. Then \"is it safe to ship?\"\nbecomes a thing you run rather than a thing you remember, and it stays true as the codebase grows.
\n\nThat is also what makes a coding agent's work verifiable. An agent with one unambiguous command can\ncheck itself and fix what it broke before you ever see the diff. Without one, \"done\" is something it\nasserts. That is most of the argument in how to write a guide file your agent will actually\nfollow.
\n\nSome things that feel urgent and are not, before you have customers:
\n\nDo the first four. Automate as much of the rest as you can. Then launch, because the fastest way to\nlearn what actually matters is to have real customers using it.
\n","date_published":"2026-07-31T00:00:00+00:00","date_modified":"2026-07-31T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["security","how-to","launch"]},{"id":"https://shiponeshot.com/blog/background-work-without-extra-services","url":"https://shiponeshot.com/blog/background-work-without-extra-services","title":"Do you need Redis to run background jobs?","summary":"No. A queue on your existing database removes a service to run, secure, and pay for. The real tradeoff, and four rules that make jobs reliable.","content_html":"Do you need Redis to run background jobs?
\n\nNo. For most products a queue that runs on your existing database is the better choice: one less\nservice to run, secure, back up, and pay for, and jobs that participate in the same transactions as\nyour data. The historic reason to reach for a separate in-memory store was throughput, and the\nthreshold where that actually matters is far higher than most products ever reach.
\n\nHere is the real tradeoff and what actually makes jobs reliable, which is not the queue you picked.
\n\nAnything that should not happen while somebody waits for a page:
\n\nThe rule of thumb: if it can fail independently of the request, or take longer than the person is\nwilling to wait, it belongs in a job.
\n\nOne less service. A separate queue store is a thing to install, configure, secure, monitor, back\nup, upgrade, and pay for. Removing it removes all of that at once, and at small scale it is a\nmeaningful share of your operational surface.
\n\nJobs and data stay consistent. This is the technically interesting advantage. If enqueuing a job\nis a write to the same database as the change that triggered it, both happen in the same transaction.\nEither the order is created and the confirmation email is queued, or neither is.
\n\nWith a separate store you get the classic split-brain: the database write succeeds and the enqueue\nfails, so the order exists and nobody is told. Or the enqueue succeeds and the transaction rolls\nback, so a job runs for an order that does not exist. Both are avoidable, and avoiding them takes\ncare you would rather spend elsewhere.
\n\nJobs survive. They are rows. A restart does not lose them, and you can query them with the tools\nyou already have.
\n\nYou can inspect it. Debugging a stuck queue is a query, not a specialised client.
\n\nThroughput has a ceiling. A separate in-memory store handles far more jobs per second. If you are\nprocessing tens of thousands per minute, you will feel the difference.
\n\nPolling has a cost. A database queue checks for work periodically rather than being pushed to,\nwhich means a small constant load and a small latency floor. Neither is noticeable at ordinary\nvolumes.
\n\nVery large backlogs are heavier. A queue table with millions of rows needs attention in a way a\nsmaller one does not.
\n\nThe honest summary: the crossover point is far above where most products live, and the operational\nsaving is immediate. Start with the database, and if you ever genuinely outgrow it, you will have\nreal numbers to make the change with.
\n\nThe queue is the least important decision here. These are what determine whether your jobs work.
\n\nThe most important rule, and the most commonly broken.
\n\nJobs get retried. A worker dies mid-run, a network call times out, a deploy interrupts things. A job\nthat ran halfway and gets retried will run its first half again.
\n\nSo \"send the welcome email\" must not send two. \"Charge the customer\" must not charge twice. The usual\nfixes are to record that the work was done and check that record first, or to write the operation so\nthat doing it again changes nothing after the first time.
\n\nThis is the same property payment webhooks need, for the same reason,\nand it is worth internalising once: anything that can be delivered more than once will be.
\n\nEnqueue the identifier and load the record inside the job.
\n\nIf you serialize a whole object into the queue, the job runs against a snapshot from whenever it was\nenqueued, which may be minutes or hours stale. Worse, if the record was deleted in the meantime, you\nare operating on something that no longer exists. Load it fresh, and handle the case where it is\ngone.
\n\nNot might. Will. Networks fail, providers have bad minutes, records disappear.
\n\nConfigure retries with increasing delays, decide what happens after the last one, and make sure\nfailures are visible somewhere you will actually look. A queue that silently drops work is worse than\nno queue, because you believe the work happened.
\n\nEasy to miss and important. A job runs with no request and no current account, so all the automatic\nscoping that protects your controllers does not apply.
\n\nPass the account identifier into the job and scope every query inside it explicitly. This is one of\nthe places tenant isolation usually gets\nmissed, precisely because the surrounding machinery is absent.
\n\nRecurring jobs, nightly cleanups, digests. Two things to watch.
\n\nOverlap. If a job runs every five minutes and one run takes six, you now have two running at\nonce. Decide whether that is safe, and if not, prevent it.
\n\nDuplication across servers. If you ever run more than one application server, each will try to\nrun the schedule. Make sure exactly one does.
\n\nFewer moving parts is a feature. It is the same logic that makes one small server the right\nanswer for longer than people expect.
\n","date_published":"2026-07-29T00:00:00+00:00","date_modified":"2026-07-29T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["jobs","how-to"]},{"id":"https://shiponeshot.com/blog/building-with-hermes","url":"https://shiponeshot.com/blog/building-with-hermes","title":"What is it like to build an app with Hermes?","summary":"Hermes keeps context as you go and runs the same core wherever you drive it from. Here is what that changes about a build session, and what to set up first.","content_html":"What is it like to build with Hermes across terminal, chat, and desktop?
\n\nThe distinctive part is continuity. You can start a change in your terminal, ask a follow-up question\nfrom a chat window, and pick it up again later without re-explaining what you are building. That\nmatters most on the second and third weeks of a project, when the codebase has grown past what fits\nin one conversation and the expensive thing is no longer writing code but re-establishing context.
\n\nWhat it does not change is the need for that context to be written down somewhere the agent can read.
\n\nThis is the trap worth naming early.
\n\nWhen an agent remembers your project, it is tempting to stop writing anything down and just tell it\nthings. That works until the moment it does not: a new session, a different surface, a teammate, or\nsimply a conversation long enough that the early part stops mattering.
\n\nA written guide file is different from remembered context in one important way: it is the same for\nevery session, and you can review it. If the rule \"every query is scoped to the account\" lives only\nin a conversation, you cannot audit it, and you will not notice when it stops being followed.
\n\nSo use the continuity for what it is good at, which is the running state of what you are building,\nand keep the invariants in a file.
\n\nSame as everywhere, and short:
\n\nWith those in place, a session that starts from any surface begins in roughly the same position.
\n\nThe request is ordinary:
\nAdd a waitlist: an email address, a source, and a timestamp.\nFree feature, not behind the paywall.\nTwo things are doing work in that prompt. \"Free feature, not behind the paywall\" is a product\ndecision the agent cannot infer, so you supply it. Everything else it can find: that a waitlist entry\nbelongs to an account, that queries go through the current account, that a resource ships with tests,\nall of that is in the codebase already.
\n\nThe output is the same shape as any other feature here: model, migration, permission policy,\ncontroller, screens, route, tests. You review the migration and the policy carefully and the rest\nquickly.
\n\nThree places, concretely.
\n\nThe second feature. When you ask for something that relates to what you built last week, it\nalready knows the shape you chose and does not propose a different one.
\n\nDebugging across sessions. \"That thing we changed on Tuesday broke sign-in\" is a usable sentence\nrather than a research project.
\n\nAsking from wherever you are. The most common real use is not building at all, it is asking a\nquestion about your own codebase from a phone. \"What decides whether an account can use the paid\nfeature?\" is a question with an answer, and getting it without opening a laptop is genuinely useful.
\n\nRemembered context drifts. Something true in week one stops being true in week three, and unless\nyou correct it, it keeps being applied. Periodically re-state the important invariants and, better,\nput them in the guide file where they cannot rot silently.
\n\nConvenience encourages vagueness. Because asking is easy, requests get shorter, and short\nrequests are ambiguous requests. The agent fills ambiguity with reasonable defaults, and reasonable\ndefaults are how you end up with a feature nobody asked for.
\n\nVerification is easy to skip from a chat surface. Running the test suite from a terminal is\nnatural. Remembering to run it after a change you made from a message thread is less so. Decide that\nnothing counts as done until the checks pass, regardless of where the change came from.
\n\nNone of the four categories where generated code is plausibly\nwrong get safer because the agent remembers your project.\nSign-in, payments, email deliverability, and customer data separation are best handled by already\nhaving them, tested, before the first prompt. That is the argument for starting from a\nkit.
\n\nThe same loop with other agents: Claude Code,\nCodex, Cursor, and\nOpenClaw.
\n","date_published":"2026-07-28T00:00:00+00:00","date_modified":"2026-07-28T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","hermes","walkthrough"]},{"id":"https://shiponeshot.com/blog/charging-for-your-app","url":"https://shiponeshot.com/blog/charging-for-your-app","title":"How do you charge for your app without building billing?","summary":"The checkout is the easy half. The whole flow, why the webhook is the source of truth, and four failures that let people use what they never paid for.","content_html":"How do you charge for your app without building a billing system?
\n\nUse a payment provider's hosted checkout, and treat their webhook as the only source of truth about\nwhat someone has paid for. That is the whole architecture. The mistake that costs people real money\nis thinking the checkout is the feature, when the checkout is perhaps a fifth of it. The other four\nfifths is keeping your idea of who has paid in sync with reality, forever, without anyone at a\nkeyboard.
\n\nHere is the complete flow and the four ways it breaks.
\n\nSteps 5 and 6 are the ones people collapse into step 4, and that is where the trouble starts.
\n\nThe redirect is a courtesy. The webhook is the fact.
\n\nConsider what happens when the redirect does not arrive. The customer pays and closes the tab. Their\nphone loses signal at the moment of return. The browser crashes. A corporate proxy eats it.
\n\nIn every one of those cases the money has moved and the customer has nothing, because your only\nrecord of the payment was a page they never loaded. They will write to support, correctly annoyed,\nand you will fix it by hand.
\n\nThe webhook has none of those failure modes. It is a server-to-server call from the payment provider,\nretried on failure until it succeeds. Build on it, and use the success page for nothing more than\nsaying thank you.
\n\nYour webhook endpoint is a public URL that writes to your database. Without signature verification,\nanyone who finds it can post a message saying \"this account has an active subscription\", and your\napp will believe it.
\n\nThere is no error state for this. It works exactly as designed, for everyone, including people who\nhave not paid. Every provider signs its webhooks and gives you a secret to check against. Use it, and\nreject anything that fails.
\n\nPayment providers retry. If your endpoint is slow, or returns an error, or the network hiccups, the\nsame event arrives again. This is not an edge case, it is the documented design, and it happens most\nduring outages when retries pile up.
\n\nSo handling an event twice has to do exactly what handling it once did. Record the event id and skip\nones you have seen, or write the update so that applying it repeatedly changes nothing after the\nfirst time. Either works. Neither is optional.
\n\naccount.paid = true seems reasonable on the day of purchase and is wrong by the end of the month.
Subscriptions change state on their own: they renew, they fail to renew, they get cancelled at the\nend of a period, they get refunded, they get disputed. What you need to store is the current state\nand the date it runs until, and then answer \"may this account use the paid feature?\" by consulting\nboth.
\n\nThe concrete version: store the status and the period end, and let the webhook keep them current. Do\nnot compute access once and cache it in a boolean nobody updates.
\n\nHiding the button is not access control. If the only thing stopping an unpaid account from using a\npaid feature is that the link is not rendered, then the feature is available to anyone who types the\naddress.
\n\nThe check belongs on the server, on the request path, in one place that every paid feature shares.\nOne line in a controller, not a condition scattered through your screens.
\n\nBriefly, because it changes what you build.
\n\nOne-time is simpler: it either happened or it did not, and there is no ongoing state to track.
\n\nSubscriptions are more work because of everything in failure three, but they are what most\nproducts need, and the machinery you build is the same machinery you would need for renewals anyway.
\n\nUsage-based is a different problem entirely, involving metering and reporting, and it is worth\nbeing sure you need it before taking it on.
\n\nIf your product has an iPhone or Android app and you sell digital goods, both stores require you to\nuse their in-app purchase system, and both take a cut of up to 30%.
\n\nThis is not a technical detail, it is the largest line item in what it costs to run an\napp. It also means a second purchase path with its own receipts and\nits own webhooks, arriving at the same question: is this account currently entitled?
\n\nThe way to keep that manageable is to make entitlement a single concept in your codebase that both\npaths write to, rather than two parallel systems that disagree. There is more on that in getting\nyour web app into the app stores.
\n\nThe thing that makes billing miserable to work on is that exercising it usually means real money, or\na test-mode account and a lot of clicking.
\n\nThe alternative is a seam: a real client when credentials are present, and a deterministic local\nstand-in when they are not. The same code path, a different implementation behind it. That means the\nentire purchase flow runs in process on your laptop, and your test suite can exercise subscribe,\ncancel, and expire without touching the network.
\n\nIt is also what lets a new developer, or a coding agent, run and modify the billing flow on the first\nday without anyone handing them a key.
\n\nThis is one of the four things worth not building\nyourself, because a webhook that skips signature\nverification looks exactly like one that does not.
\n","date_published":"2026-07-27T00:00:00+00:00","date_modified":"2026-07-27T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["payments","how-to"]},{"id":"https://shiponeshot.com/blog/sign-in-without-passwords","url":"https://shiponeshot.com/blog/sign-in-without-passwords","title":"Should you build sign-in without passwords?","summary":"Emailed codes and social sign-in remove the password database and the reset flow. What you gain, what you take on, and the detail everyone gets wrong.","content_html":"Should you build sign-in without passwords?
\n\nFor most new products, yes. Dropping passwords removes four things you would otherwise own forever:\na password database worth stealing, a reset flow, the rules about length and reuse, and the support\nrequests that come from all three. You replace them with two dependencies, email delivery and the\nidentity providers you accept, and one detail that almost everyone gets wrong the first time.
\n\nHere is the trade in full, including the part that bites.
\n\nTwo mechanisms, usually together:
\n\nA code by email. Someone types their address, you email a short code, they type it back. There is\nnothing to remember and nothing stored that is worth stealing.
\n\nSocial sign-in. Continue with Google or Apple. The provider proves who they are, and you never\nhandle a credential at all.
\n\nOffering both covers nearly everyone: people who have a Google or Apple account use the button, and\neveryone else uses their email.
\n\nNo password database. The single most valuable property. A stolen password file is a breach that\nfollows your customers to every other site where they reused that password. If you never had one,\nthat entire class of incident cannot happen to you.
\n\nNo reset flow. Password reset is a small feature with a large surface: token generation,\nexpiry, single use, and a set of enumeration questions about whether \"no account with that address\"\nis a safe thing to say. Passwordless sign-in and password reset are nearly the same flow, so you\nbuild it once instead of twice.
\n\nLess support. \"I cannot log in\" is one of the highest-volume support categories for any product,\nand most of it is password-shaped.
\n\nBetter completion. Fewer fields and nothing to remember, on a phone especially.
\n\nBe honest about these, because they are real.
\n\nYour sign-in now depends on email delivery. If your mail lands in spam, nobody can get in. This\nturns deliverability from a marketing concern into an availability\nconcern, and it is the strongest argument for setting up your DNS records properly before launch\nrather than after.
\n\nSign-in gets slower. Switching to an inbox and back is more work than a saved password in a\nbrowser. Social sign-in avoids this for the people who use it, which is a good reason to offer both.
\n\nYou depend on identity providers. If someone loses access to their Google account, they lose\naccess to yours. Accepting email codes as well as social sign-in gives them a route back.
\n\nCodes are a credential. They need the same care as a password: hashed at rest, short expiry, a\nlimited number of attempts, and rate limits per address and per network. A six-digit code with\nunlimited guesses is a four-digit problem.
\n\nHere is the one, and it is worth reading twice.
\n\nSomebody signs up with sam@example.com using an emailed code. Two months later they come back and\nclick \"Continue with Google\", which is the same address.
Do they get their existing account, or a brand new empty one?
\n\nGet this wrong and you create a silent duplicate. The customer sees an empty account, assumes their\ndata is gone, and writes to support saying they lost everything. Meanwhile you now have two account\nrecords for one human, possibly two subscriptions, and a reconciliation job to do by hand.
\n\nThe fix is structural, not clever: every route into the system creates or finds an account through\nexactly one function. Email codes call it. Google calls it. Apple calls it. Anything you add later\ncalls it. That function looks up by email address and decides once.
\n\nThe reason to do it this way rather than \"carefully, in three places\" is that three places is how it\nbreaks. Each provider gets added at a different time by a different person, and the third one forgets.
\n\nOne chokepoint. Every time.
\n\nThere is a subtlety underneath that, and it matters for security rather than convenience.
\n\nLinking accounts by email address is only safe if you trust that the provider verified the address.\nGoogle and Apple do. An identity provider that lets someone claim an arbitrary unverified email would\nlet an attacker take over an existing account by signing in with its address.
\n\nSo: link on email, but only when the address is verified, and treat \"verified\" as something you check\nrather than assume.
\n\nA checklist you can hold your implementation against:
\n\nTwo cases, mainly.
\n\nYour customers cannot receive email reliably. Shared inboxes, locked-down corporate mail, or a\ncontext where checking email mid-task is genuinely disruptive.
\n\nEnterprise requirements. Larger customers may want single sign-on through their own identity\nprovider, which is a different project. The good news is that a codebase built around one\naccount-creation chokepoint is the easy version of adding it later.
\n\nPasswordless sign-in trades a password database and a reset flow for a dependency on email delivery.\nFor most products that is a clearly good trade, provided you do two things: take\ndeliverability seriously, because sign-in now depends on it, and route\nevery sign-in method through one account-creation function so that the same person always gets the\nsame account.
\n\nThis is one of the four things worth not building\nyourself, precisely because the account-merge bug looks like\nworking code right up until it does not.
\n","date_published":"2026-07-26T00:00:00+00:00","date_modified":"2026-07-26T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["sign-in","how-to"]},{"id":"https://shiponeshot.com/blog/going-live-on-your-own-server","url":"https://shiponeshot.com/blog/going-live-on-your-own-server","title":"How do you put your app on your own server?","summary":"One command, a $5 box, and a container. What running your own server involves in 2026, what it costs, and when a managed platform is the better answer.","content_html":"How do you put your app on your own server?
\n\nRent a small virtual machine for $5 to $20 a month, install nothing but a container runtime, and\nuse a deploy tool that builds your app into an image, ships it to the box, and swaps it in with no\ndowntime. Setup takes an afternoon the first time and one command every time after. For most products\nbefore serious scale, this is cheaper, faster, and less surprising than a managed platform.
\n\nHere is what is actually involved, and when you should not do it.
\n\nIt does not mean a rack, and it does not mean configuring web server software by hand. The modern\nshape is:
\n\nYou do not manage the machine so much as replace what runs on it. If the box is ever damaged in a way\nyou cannot explain, the answer is to make a new one and deploy again, which takes minutes.
\n\nA server. One virtual machine. Two shared cores and 2 to 4 GB of memory handles far more traffic\nthan most people expect. $5 to $20 a month.
\n\nA domain, pointed at the server. $10 to $15 a year.
\n\nA container registry to hold your images. Free tiers cover a small app comfortably.
\n\nTLS, which is free and automatic. Nobody should be paying for a certificate.
\n\nThat is the entire bill. Compare with a managed platform, where the equivalent setup with a managed\ndatabase and a worker process usually lands somewhere between $50 and $200 a month for the same\ntraffic.
\n\nThe one that generates the most argument, so here is the direct answer: for most products, at most\nstages, SQLite on the same server is genuinely fine.
\n\nNot a compromise, not a starter tier. Fine.
\n\nIt is fast, because there is no network between your app and its data. It is simple, because there is\nno second service to run, secure, or pay for. And modern setups handle concurrent writes far better\nthan the old reputation suggests.
\n\nYou need a separate database server when you need multiple application servers sharing one dataset,\nor when your working set genuinely outgrows one machine. Both are real, and both are much further\naway than people assume. Until then, a separate database is a bill and an operational burden that\nbuys you nothing.
\n\nThe same logic applies to your job queue and your cache. If they can live in your database rather\nthan requiring a separate service, that is one less thing to run, monitor, and pay for.
\n\nWhat a good deploy does, in order:
\n\nStep five is the one that matters. Without it, a deploy that fails to boot takes your site down and\nyou find out from a customer. With it, the new container never receives traffic and the old one keeps\nserving, so a broken deploy is a non-event.
\n\nBeing honest: running your own server is not zero work. It is a small amount of specific work.
\n\nBackups. Nobody else is doing this for you. Automated, off the machine, and restored at least\nonce as a test. A backup you have never restored is a hypothesis. This is the single most important\nitem on the list and the most commonly skipped.
\n\nOperating system updates. Unattended security updates handle most of it. Reboot occasionally.
\n\nMonitoring. At minimum, something that tells you when the site is down. A free uptime checker\ncovers it.
\n\nLogs. Know where they are before you need them at two in the morning.
\n\nSecrets. Environment variables on the server, never in the repository. Somebody should check for\ncommitted secrets automatically, because everyone commits one eventually.
\n\nThat is the list. It is perhaps an hour of setup and very little ongoing attention.
\n\nNot never. Specifically:
\n\nOtherwise the arithmetic favors the small server, and it keeps favoring it for a long time.
\n\nWhatever you choose, the property worth insisting on is that deploying is one command and that it\nis safe to run at any time.
\n\nThe moment deploying becomes a checklist, people deploy less, changes pile up, and every release\nbecomes bigger and riskier than the last. That is a much more expensive problem than any hosting bill,\nand it is the real argument for setting this up properly at the start rather than \"once things are\nworking\".
\n\nThe costs sit alongside everything else in what it actually costs to start an\napp, and the short version is that hosting is not where your money\ngoes.
\n","date_published":"2026-07-25T00:00:00+00:00","date_modified":"2026-07-25T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["deploy","how-to"]},{"id":"https://shiponeshot.com/blog/what-it-costs-to-start","url":"https://shiponeshot.com/blog/what-it-costs-to-start","title":"What does it actually cost to start an app in 2026?","summary":"A realistic breakdown of the money and the time: what you pay before your first customer, what is genuinely free, and where the real cost sits.","content_html":"What does it actually cost to start an app in 2026?
\n\nIn money, less than most people expect: you can run a real product with paying customers for roughly\n$5 to $30 a month in infrastructure, plus payment processing of about 2.9% plus 30 cents per\ntransaction. In time, more than most people expect: four to eight weeks of building before the\nfirst customer can do anything useful, and almost all of it goes to work that is identical in every\nproduct. The time is the real cost, and it is the one worth attacking.
\n\nHere is the breakdown behind those numbers.
\n\n| Item | \nRealistic cost | \nNotes | \n
|---|---|---|
| Domain | \n$10 to $15 per year | \nThe one unavoidable purchase | \n
| Server | \n$5 to $20 per month | \nA small instance handles far more than people assume | \n
| Database | \n$0 | \nSQLite on the same box is genuinely fine at this stage | \n
| Background jobs | \n$0 | \nIf your queue runs on your database, there is nothing extra to pay for | \n
| TLS certificate | \n$0 | \nAutomatic | \n
| Email sending | \n$0 to start | \nMost providers have a free tier in the thousands of messages | \n
| Error tracking | \n$0 to start | \nFree tiers are generous | \n
| Payment provider | \n$0 | \nNo monthly fee, they take a cut of transactions | \n
| Monthly total | \n$5 to $30 | \n\n |
That is not a trick. A single small server running one application with a local database will serve a\nsurprising number of customers before anything needs to change.
\n\nThe instinct is to over-provision for scale that has not arrived. Resist it. The costs that actually\ngrow are:
\n\nThat last one is where most early budgets go, and it buys very little at a stage where you have one\nserver and one developer.
\n\nHere is where four to eight weeks goes for a competent developer building from an empty directory.\nTreat these as ranges, not promises, because they vary with experience and how much you cut.
\n\n| Work | \nTypical time | \n
|---|---|
| Accounts, sign-in, sessions, social login | \n5 to 10 days | \n
| Payments, webhooks, subscription state, entitlement | \n5 to 10 days | \n
| Email: provider, templates, DNS records, deliverability | \n2 to 4 days | \n
| Separating customer data, permissions | \n3 to 6 days | \n
| Background jobs | \n1 to 3 days | \n
| Security hardening, rate limits, data export and deletion | \n3 to 5 days | \n
| Deployment, TLS, CI | \n2 to 5 days | \n
| Subtotal, before any of your product | \n21 to 43 days | \n
| Your actual product | \nhowever long it takes | \n
Put a cost on that. At a contractor rate of $600 a day, the subtotal alone is $12,000 to $26,000. If\nyou are doing it yourself, it is four to eight weeks you are not spending on the thing that\ndifferentiates you, and four to eight weeks is long enough for the idea to lose its urgency.
\n\nThat is the real cost of starting an app, and it has almost nothing to do with your server bill.\nThose ranges are estimated from the outside. There is a measured version of this same table, counted\nline by line against a real codebase, in how long it takes to build the parts every app\nneeds.
\n\nPartly, and less than the marketing suggests.
\n\nAn agent will absolutely produce all of the above faster than you would type it. What it will not do\nis make the review cheaper. You still have to check the four places where generated code looks\nright and is not, and those are the slowest things to\nreview because there is no failing test to point at.
\n\nThe other thing that happens is that most of the first run disappears into\nplumbing rather than into your idea, because the plumbing is what\nhas to exist first.
\n\nSo an agent compresses the twenty-one to forty-three days meaningfully. It does not remove them, and\nwhat is left is the part you least want to be responsible for.
\n\nDo not build the identical part. Start from a codebase where it already exists, is tested, and is\ndocumented, and spend your weeks on the part that is yours.
\n\nThat is what One Shot is, and it costs $299 a year at the regular price. Against a subtotal of\n$12,000 to $26,000 of equivalent work, that arithmetic is not subtle. The honest caveat is the one\nworth repeating: it is a Ruby on Rails codebase, and if nobody on your team can maintain that, none\nof this arithmetic applies to you.
\n\nThere is a full list of what that includes, and what it deliberately does not, in everything One\nShot gives you on day one.
\n\nAttack the last line. The others largely take care of themselves.
\n","date_published":"2026-07-24T00:00:00+00:00","date_modified":"2026-07-24T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["basics","getting started"]},{"id":"https://shiponeshot.com/blog/whats-in-the-box","url":"https://shiponeshot.com/blog/whats-in-the-box","title":"What is One Shot, and what do you get on day one?","summary":"One Shot is a working app with accounts, payments, email, jobs, security, and mobile shells already built and tested. The complete list of what is included.","content_html":"What is One Shot, and what do you get on day one?
\n\nOne Shot is a complete, working application that you build your product on top of. Accounts and\npasswordless sign-in, subscriptions and payments, transactional email, background jobs, permissions,\nsecurity hardening, and iPhone and Android app shells are all built, tested, and documented before\nyou write a line. It runs on a fresh clone with no external accounts and no API keys, and you own\nthe source. A license is $299 per year at the regular price and includes updates while it is active.
\n\nBelow is the complete list, including the parts that are deliberately not included.
\n\nYou have an idea. The distance between that idea and something a customer can pay for is mostly work\nthat is identical in every product. One Shot is that work, already done, so you or your coding agent\ncan start at the part that is actually yours.
\n\nbin/check, that runs the tests, the linter, a static security scanner, a\ndependency vulnerability audit, and a secret scanner. Measured against the checklist that makes an\napp safe to launch.CLAUDE.md and AGENTS.md) that tells an agent the one right way to do each\nthing in this codebase.This is the part most descriptions leave out, and it is the part you need in order to decide.
\n\nUnder the hood it is a Ruby on Rails application. That is not a marketing detail, it is the most\nimportant compatibility question, and it cuts both ways.
\n\nIf you or your team can read and maintain that, you are getting a conventional, well-tested codebase\nthat you own completely. If nobody on your team can, then a starter kit will not save you six weeks;\nit will hand you a permanent dependency on a stack you do not speak. That is worth knowing before you\nsubscribe, not after.
\n\nEverything is written to be conventional and readable on purpose. No metaprogramming, no custom\ndomain-specific languages, no clever abstractions. Boring code is easier for a person to change and\nmuch easier for a coding agent to extend correctly.
\n\nThe regular price is $299 per year, and the pricing page always shows what is actually\nbeing charged today. That includes the full source, delivered privately, and updates for as long as\nthe license is active. If you stop renewing, you keep the code you have.
\n\nThere is a fuller breakdown of how that compares to the alternatives in what it actually costs to\nstart an app.
\n\nClone it, run the setup command, and it is already running with a working sign-in and a working\npurchase flow, using local stand-ins for every external service. Then run the bootstrap step, which\nrenames the application, sets your brand, and removes the example feature. Then build your product.
\n\nThe first thing most people do is point a coding agent at it. There are walkthroughs for Claude\nCode, Codex, Cursor, Hermes, and OpenClaw.
\n","date_published":"2026-07-18T00:00:00+00:00","date_modified":"2026-07-18T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["basics","getting started"]},{"id":"https://shiponeshot.com/blog/where-the-first-run-goes","url":"https://shiponeshot.com/blog/where-the-first-run-goes","title":"Why does your first agent run disappear into plumbing?","summary":"Ask a coding agent for an app and most of its first run goes to sign-in, payments, and email, not your idea. Why that happens, and what to do about it.","content_html":"Why does your first agent run disappear into plumbing?
\n\nBecause \"build me an app where people can share reading lists\" contains one sentence about reading\nlists and an unwritten twenty about everything that has to exist before a reading list can have an\nowner. Your agent reads the whole request, including the unwritten part, and starts at the bottom.\nBy the time it reaches your actual idea it has spent most of its run, most of its context window, and\nmost of your patience on work that is identical in every product.
\n\nNothing has gone wrong. That is what you asked for.
\n\nTake that request literally and see what it implies.
\n\nFor someone to have a reading list, there has to be a someone, which means accounts. For accounts\nto be useful across visits, there has to be sign-in, which means sessions, and email verification,\nand a decision about passwords or codes or social sign-in. For a list to be private, every query has\nto be scoped to its owner. For any of it to be online, there has to be a server, a database, a\ncontainer, and a deploy.
\n\nAnd that is the free version. Charge for it and you add a checkout, a webhook, a subscription record,\nand the logic that decides whether this account may currently use the feature.
\n\nSomewhere in there is the part you actually care about: what a reading list is, what makes yours\ndifferent, why anyone would use it. It is perhaps five percent of the code and effectively all of the\nproduct.
\n\nTwo reasons, and both are good reasons.
\n\nDependency order. You cannot write a reading list that belongs to a user before the user exists.\nThe agent is not procrastinating, it is topologically sorting. The plumbing genuinely does come\nfirst.
\n\nAmbiguity. Your one sentence about reading lists is under-specified, and your agent knows it.\nSign-in is not under-specified at all; there is a well-known right answer it has seen thousands of\ntimes. So it does the confident work first and arrives at the ambiguous work later, with less room\nleft, which is precisely backwards from what you want.
\n\nIt is tempting to think of this as a waste of money. It is worse than that, in three specific ways.
\n\nThe interesting decisions happen last, when there is least room. Your feature is the part that\nneeds your judgment, several rounds of it. It gets whatever is left of the run and the context\nwindow after the plumbing has consumed both.
\n\nYou cannot review what you got. By the end you have a large diff spanning sign-in, payments,\nemail, and your feature. The question you need to answer is not \"does this work\", it is \"is this\nright in the four places where wrong and right look identical\". That is a slow, careful read of code\nyou did not write and did not want to think about. Most people skim it, and the failures that skim\nmisses surface months later.
\n\nThere is nothing to check the work against. In a codebase with no test suite the agent has no way\nto know whether it has finished. It cannot run anything. It reports success because the code it wrote\nlooks like code that works, which is the only signal available to it.
\n\nNot a better prompt. The problem is not phrasing, it is the starting position.
\n\nPoint the agent at a codebase where accounts, sign-in, payments, email, jobs, permissions, and deploy\nalready exist, are tested, and are documented, and every constraint above inverts:
\n\nThat last one is the biggest change, and it is the one people underestimate. An agent that can verify\nits own work behaves differently from one that cannot. It stops guessing.
\n\nA subtle point that is easy to miss: a kit gives an agent more than working plumbing. It gives it a\ngrain to follow.
\n\nWhen every existing feature is built the same way, an agent adding the next one has a template.\nIt does not have to invent a structure, and it does not have to guess whether you would prefer this\nor that, because there is a worked example sitting right there and a written note saying \"copy this\nshape\".
\n\nThat is why the guide file matters so much. A short document that says \"here is the one right way to\ndo each thing, here is the file to copy, here is the rule that must never be broken\" removes most of\nthe decisions an agent would otherwise make on your behalf, badly, at three in the morning. It is\nworth writing carefully, and it is covered in how to write a guide file your agent will actually\nfollow.
\n\nHere is the shape of a run that is going well. You ask for a feature. The agent reads the guide file,\nfinds the existing example of a similar feature, copies its structure, writes the model, the\npermission rules, the screens, and the tests, runs the whole suite, fixes the two things that failed,\nand comes back with a diff that is entirely about your feature and nothing else.
\n\nThat is not a better agent. It is the same agent, standing somewhere else when it starts.
\n\nYour first run does not disappear because your agent is weak. It disappears because you asked it to\nbuild a foundation, and foundations are large, mandatory, and identical everywhere.
\n\nGive it the foundation and ask for the building.
\n\nIf you want the concrete list of what that means, see what a starter kit\nis and everything One Shot gives you on day\none.
\n","date_published":"2026-07-17T00:00:00+00:00","date_modified":"2026-07-17T00:00:00+00:00","authors":[{"name":"wbnns"}],"tags":["agents","getting started"]}]}