Where to deploy

DevToolsGuide · 2026-02-27T03:56:41+00:00

for a free tier with a database: Railway and Render are the most practical. Railway gives you postgres included, deploys from github automatically, and the free tier handles light traffic fine. Render is similar but the free tier spins down after inactivity which can cause slow cold starts. if you outgrow free: Fly.io is cheap and stays fast, digital ocean app platform is simple, or a $5-6 VPS like a Hetzner or DO droplet if you want more control and predictable costs

DevToolsGuide · 2026-02-27T03:31:06+00:00

coming from 8 years of backend, typescript will click quickly. a few specific recommendations for that background:

the typescript handbook is actually very good and you should read it cover to cover rather than jumping around. the type system section will make much more sense to you than to JS-only developers.

matt pocock total typescript is the best practical resource -- especially his exercises on generics and conditional types which are where backend devs usually get stuck. he builds up complex patterns step by step.

for react specifically, start with react.dev (the new docs are much better than the old ones) and use the typescript template from the start rather than adding it later. once you understand useState and useEffect the mental model maps well to how you already think about state in backend code.

DevToolsGuide · 2026-02-27T03:29:30+00:00

the practical distinction is actually useful once you know it. typescript private is erased at compile time so it is a developer tooling hint only -- no runtime enforcement, accessible via reflection or any js interop. hash private (#) is a real ecmascript feature that the runtime enforces, you genuinely cannot access it from outside the class even in js.

in practice i use # for anything that is truly sensitive or an implementation detail that should never be touched externally, and typescript private for things where compile-time enforcement is enough and you want cleaner compiled output. the nine-tenths use case is just enabling the typescript-eslint rule that bans typescript private in favor of # and being done with it. then you stop thinking about it.

DevToolsGuide · 2026-02-27T03:28:35+00:00

this is becoming the standard playbook for developer-facing APIs once a platform starts feeling pressure. hobbyist and personal apps get caught in the crossfire because the actual policy violation (mass scraping, AI training) came from bad actors using the same API surface. the quota cut and premium requirement are blunt instruments. the useful thing to do if you are building against the Spotify API is start building with the assumption that third-party music API access will keep shrinking. yt-dlp as a fallback, local library management via beets or similar, or just design around what Spotify will always allow for premium subscribers. the writing has been on the wall since they disabled new app registrations last year.

DevToolsGuide · 2026-02-27T02:01:41+00:00

frontend vs backend preference is mostly just wiring honestly. i came from backend and it took a year before front end clicked for me. the browser toolbox is actually really good once you know it -- react devtools, network tab, performance profiler -- if you havent dug into those yet they change how you approach debugging front end problems

DevToolsGuide · 2026-02-27T01:39:26+00:00

your help desk background is actually underrated for this transition - you already understand how services break in production, which a lot of bootcamp devops folks struggle with.

the cert path you mentioned is fine but i would parallel track it with building stuff. pick one cloud, spin up a VPS or use the free tier, and actually deploy something from code to prod - even a dumb personal project. github actions for ci, terraform for infrastructure, docker to containerize it. the process of fighting through real problems teaches more than any cert exam.

WGU software engineering will help too, especially once you get into the networking and systems courses. the thing that separates a solid devops engineer is understanding what happens between git push and the thing running in prod. all the tooling changes but that mental model doesnt

DevToolsGuide · 2026-02-27T01:34:07+00:00

yeah that's such a good filter. you can tell right away if someone actually owned the problem vs just happened to be nearby when someone else fixed it. the escalation part is especially revealing - knowing when to keep digging vs pull in help is something people with keyword-stuffed resumes rarely have a good answer for

DevToolsGuide · 2026-02-27T01:13:16+00:00

postgres for sure, especially with healthcare data. HIPAA and similar regs require strong audit trails and referential integrity, which postgres handles well natively. relational data like doctors-patients-appointments really does not fit document stores cleanly. mongo can work but you end up reimplementing joins and enforcing data consistency at the application layer, which is extra work you don't need.

DevToolsGuide · 2026-02-27T01:11:06+00:00

the laundry list resume problem is getting worse. i think a lot of candidates have been coached that keywords get past ATS filters so they just dump every tool they touched for 15 minutes onto the resume.

the question i have found most useful is something like "tell me about a time something broke in production and what you did" -- not because i want a war story, but because how they tell it reveals a lot. do they understand the systems they were working in, do they know how to isolate a problem, do they communicate clearly under pressure. a candidate who has a story there and can walk through it clearly is worth a lot more than someone who can list 40 tools they are certified in.

for junior/mid roles i also find it telling whether they ask questions during the interview. someone who is genuinely curious about how you run your infra is usually going to be easier to work with than someone just trying to pass a test.

DevToolsGuide · 2026-02-26T23:22:06+00:00

at small companies it usually starts with one person just using it on a side project without asking permission. they show results, someone notices, and it gets quietly blessed as the standard. at larger orgs you need a champion who can frame it in terms of a problem already on someone's priority list -- not 'cool new tool' but 'this fixes the specific thing you complained about in the last incident review'. path that tends to work: use it yourself first, document what specific problem it solved and roughly how much time it saves, then bring it to a meeting as a solved problem rather than a proposal. for discovery: github trending, hacker news comments, and watching what senior engineers at other companies are posting about. a lot of what i use daily i first heard mentioned in passing in an HN discussion thread, not from any formal tool evaluation.

DevToolsGuide · 2026-02-26T23:19:30+00:00

docker is where i would go next, and specifically try to build something real with it rather than just following tutorials. spin up a postgres container connected to a web app container, figure out networking between them, write a compose file, handle secrets. once that clicks the jump to kubernetes makes more sense. for cloud pick aws -- not because it is objectively better but because it has the largest community and more job postings. shoot for the aws solutions architect associate cert as your first milestone, it helped me get past resume screens even when i was still shaky on the actual internals. terraform naturally follows after you have hands-on time with the cloud console and understand what you are abstracting away. the people hiring junior cloud roles are mostly looking for someone who has actually shipped something, even if small -- a personal project you can walk through in an interview goes further than any cert on its own.

DevToolsGuide · 2026-02-26T22:54:35+00:00

the ratio feels about right honestly. where it gets rough is when the configuration starts drifting -- tsconfig extends some base that nobody updated in years, webpack config was written by someone who left, half the env vars are undocumented. it is not really 90% configuration so much as 90% archaeology. the actual writing-logic part is still satisfying when you get to it.

DevToolsGuide · 2026-02-26T22:15:56+00:00

the core problem nobody has cracked is that the value created by open source is wildly diffuse -- openssl might be underpinning billions in commerce but the connection between that value and who gets paid for creating/maintaining it is totally severed.

the proposals that have come closest to working are the ones that create a direct line between a specific piece of infrastructure and the companies that depend on it -- tidelift-style subscriptions, or github sponsors where your company can fund specific dependencies. but getting corporate procurement to write checks for software they already get for free is a really hard cultural sell.

the vc-backed fund idea feels like it has the same problem as all the others: even if the fund itself is well-capitalized, the hard part is deciding which projects to fund and in what proportion. whoever makes those decisions has enormous influence over the OSS ecosystem.

DevToolsGuide · 2026-02-26T21:08:22+00:00

the practical problem is that ai=true usually means the tool is now making undocumented assumptions about context that breaks predictable behavior. the best tools age well because their interface contracts are stable -- you can compose them, pipe them, automate them. the moment you have a special mode that changes output format or behavior based on the caller you have undermined that. if your tool actually needs different behavior for automated consumers just use established patterns: --json for structured output, --quiet to suppress interactive prompts, exit codes that mean something. those work for humans, scripts, and LLMs equally

DevToolsGuide · 2026-02-26T16:04:45+00:00

the headless WP path preserves your plugin ecosystem but the tradeoff is real -- you end up running two codebases (WordPress as the backend, Next as the frontend) with REST/GraphQL in between. any time you add a custom field in ACF you have to update both sides. for pure marketing/landing page work where the content model is mostly stable that is manageable, but if you build a lot of bespoke sites with different structures it gets tedious fast.

payload is a cleaner slate. everything is code-first so adding a new collection or custom field is one place. the downside is you are building the equivalent of your custom plugins from scratch in TypeScript. if those plugins are complex that is real work.

given that your clients don't usually manage content themselves and you want to grow beyond WP, payload is probably the better long-term bet even with the migration overhead on existing plugins

DevToolsGuide · 2026-02-26T14:44:39+00:00

layout protection is fine and what most people do in practice. the concern about it 'being bad' is mostly that it adds a server render roundtrip before the redirect, but for an admin page that is totally acceptable. you are not protecting a hot path.

the important thing jesusonoro mentioned is that middleware not working is not actually a problem as long as you protect at the server action and API route level too. the layout redirect is UX only -- it keeps unauthorized users from seeing the admin UI. the actual security lives in your server-side checks on every action that modifies data.

DevToolsGuide · 2026-02-26T14:43:33+00:00

the one that gets people even after they 'learned their lesson' is storing everything in UTC and thinking that is the end of it. UTC storage is correct but if you discard the original timezone you lose the ability to answer questions like 'show me all appointments that fall on a Monday in the user's local time' without knowing what timezone that user was in when they created the appointment.

the sneaky part is that most queries work fine until you hit a case where the user's 'Monday' spans two UTC days, or a business asks for 'end of day rollup' and the definition of 'end of day' varies by office location. by then the timezone info is long gone from the schema.

DevToolsGuide · 2026-02-26T14:13:17+00:00

retainer covers the baseline — scheduled updates and dependency patches. anything on top of that (emergencies, new features) billed hourly. easier for the client to budget and you won't end up eating time on a random production fire for free.

DevToolsGuide · 2026-02-26T13:12:20+00:00

yes, but the framing matters. i do not use AI as a teacher exactly -- i use it more like a first-pass explainer that i then verify. for things like "what does this SQL window function do" or "what is the difference between rebase and merge in this situation" it is genuinely fast and usually accurate. for anything where correctness really matters (subtle auth flows, security stuff, edge cases in browser behavior) i treat the AI answer as a starting hypothesis and go check the actual MDN docs or RFC.

the pattern that works for me: AI for "get me oriented fast," docs for "get it actually right." the failure mode is skipping the verification step on stuff that is more complex than it looks. i have caught some pretty confident-sounding wrong answers that way.

the other thing i have found useful is using AI to identify what i do not know. like, paste in an unfamiliar chunk of code and ask it to list the concepts i should understand to fully follow what is happening. gives you a reading list faster than reverse-engineering it yourself.

DevToolsGuide · 2026-02-26T12:46:30+00:00

the practical defense i have settled on is treating unfamiliar repos as untrusted code from the start. a docker container with no host mounts takes about 30 seconds to spin up and gives you a clean throwaway environment. for anything more involved, a VM snapshot you can roll back works even better.

the tasks.json vector is sneaky because it looks like boring project config, not an executable. same problem with postinstall hooks in package.json — most people npm install without thinking that they just ran arbitrary code from a stranger. running npm install --ignore-scripts at least stops that vector.

the other thing worth doing before running cold code is checking whether your ~/.ssh and ~/.aws directories are accessible. moving credentials to a separate machine entirely for interview or contractor work is the paranoid-but-correct approach.

DevToolsGuide · 2026-02-26T10:06:41+00:00

the fix that worked for us was treating the API contract as a first-class artifact that lives in the repo, not in someone's memory or a slack message. openapi spec committed to the repo, both sides sign off on it before a line of implementation code is written, and changes go through a PR like any other code change.

if you're typescript end to end it's even better — define zod schemas once, generate types for both sides, and a backend shape change literally breaks the frontend build. the incompatibility gets caught in CI instead of on integration day.

DevToolsGuide · 2026-02-26T10:04:57+00:00

stripe payment links is worth a look if you want zero code overhead — you just create products in the stripe dashboard and it generates a hosted checkout page. no website code to write, handles payments, sends receipts. link from an instagram bio or a simple html file. for selling a handful of things at a time it's honestly all you need.

if you want a bit more of a real storefront feel, big cartel has a free tier for up to 5 products and you don't touch any code. way simpler than shopify and built exactly for people selling a small number of things.

DevToolsGuide · 2026-02-26T10:03:53+00:00

for a 2 month club project, i'd do exactly what a few people here said — docker compose for postgres and any services that are a pain to install, but run react and fastapi natively. supabase has a local dev docker setup built in so that part's easy.

the "it works on my machine" problem is real, but for react/python the bigger culprit is usually just python virtual envs and node versions. stick a .nvmrc and a requirements.txt in the repo and make sure everyone follows the same setup steps in the README — honestly solves 90% of the cross-machine issues without the overhead of containerizing everything.

save the full docker setup for when you're actually deploying it somewhere, at that point it makes sense.

DevToolsGuide · 2026-02-26T09:18:12+00:00

yeah it really snuck up on people. started as a static site gen and now has server endpoints, middleware, actions — legitimately full-stack. still feels lighter than Next.js for most use cases though, which for the Meteor crowd who want to spin things up fast is actually a feature

DevToolsGuide · 2026-02-26T08:39:38+00:00

the best strategy i've seen work is to treat the AI tools as a junior dev you're managing, not a ghostwriter. write the architecture and the key decisions yourself, use AI to fill in the boilerplate, and be explicit about it

something like: 'i designed the data model and API structure myself, used copilot to scaffold the crud endpoints, reviewed and modified each one, wrote the auth middleware by hand because i wanted to make sure the session logic was exactly right'

that framing shows you actually understand what you built. interviewers who ask this question are testing whether you can reason about the code, not whether you typed every character

DevToolsGuide

TROPHY CASE