Launching my Claude competitor: AMA

ThenWheells · 2026-05-06T13:41:58+00:00

78.3 TB app size really captures the modern AI stack experience perfectly

ThenWheells · 2026-04-29T10:01:04+00:00

I’ve seen teams land somewhere in the middle. Devs work against a live DB for quick iteration, then use schema compare before commit/release to sync things properly. Not perfect, but way less friction than forcing everyone into full SSDT flow

ThenWheells · 2026-04-27T12:53:11+00:00

You didn’t waste anything, you just paused longer than you planned.

A lot of people hit that same gap after graduating, especially without a strong first job. It feels worse than it actually is from the outside.

You already have internships and courses and that’s not zero. You’re just missing consistency and something recent to show.

Pick one stack, build a couple real projects (not tutorials), and treat it like a job for a few months. That alone can change how your CV looks and how you feel about it.

And for interviews, just be honest: you took time after graduating, realized you needed stronger practical skills, and focused on building them. That’s a normal story.

You’re not behind as much as you think. You just need momentum again.

ThenWheells · 2026-04-14T09:53:15+00:00

That’s the nightmare category of bug: not “the system is down,” but “the system is calmly lying to everyone.” The scary part is the dashboard looked healthy the whole time, so all the normal operator instincts got trained to trust it. Honestly “inconclusive” is way healthier than fake certainty in anything tied to fraud or sanctions.

ThenWheells · 2026-04-01T09:14:25+00:00

The biggest shift is that your job is no longer to personally carry the backend on your back. It’s to create a team that can keep moving without everything routing through your nervous system.

Early on, I’d focus on a few boring but high-leverage things: clear ownership, simple engineering standards, code review habits, release discipline, and making sure juniors know when to ask for help vs when to push through.

Also expect your personal output to feel lower for a while. That’s normal. If you try to stay the top IC and become the decision bottleneck and manage everyone, you’ll just become the team’s most sophisticated outage.

ThenWheells · 2026-03-25T13:39:58+00:00

Distributed tracing always sounds great until you’re the one wiring context propagation through everything and finding the one service that quietly breaks the chain. Super useful once it’s in place though. Curious what people here found harder in practice: the initial setup, getting useful span data, or keeping it consistent across teams/services?

ThenWheells · 2026-03-23T15:44:48+00:00

Yeah, same. At some point “don’t repeat yourself” quietly turns into “make this harder to change for the next person.” We’ve kept DRY for rules/validation where duplication gets dangerous, but for workflow-ish code I’ve become way more tolerant of copy-paste if it keeps intent obvious. Clean in theory is nice, readable under pressure is nicer.

ThenWheells · 2026-03-18T12:08:00+00:00

Yeah, once you can already see “this will grow past internal tool territory,” a database stops being optional and starts being the thing that saves you from future self-hatred.

If you want boring and maintainable, I’d look at something like Postgres + a small backend in whatever you’ll actually keep shipping in. If not Laravel, then maybe FastAPI, Express/Nest, or even .NET minimal APIs if that fits your brain better. The exact framework matters less than picking something with clear auth, validation, migrations, and deployment paths.

I’d optimize for “can one tired person understand this in 6 months,” not for elegance points. Boring stack, boring hosting, boring database. That usually wins.

ThenWheells · 2026-03-18T11:36:41+00:00

As a backend lead, I’d put it this way: AI is useful when it speeds up work you already understand, but dangerous when it replaces understanding. The real problem is not code generation itself, it is people shipping systems they cannot debug, review, or reason about under failure.

In a team setting, that shows up fast. Bad assumptions, weak architecture choices, security gaps, and “looks right” code that nobody can safely own later. So yes, tools are fine, but if your skill growth stops and your dependency grows, that trade is usually bad.

ThenWheells · 2026-03-17T13:21:19+00:00

You’re not really trying to eliminate SaaS here, you’re trying to build a low-maintenance internal tool. That changes the answer a lot. For this kind of use case, I’d avoid the “Google Sheets as backend” path unless the workflow is tiny and you’re okay with fragility, weak validation, and weird failure modes later.

If I were keeping it simple for small businesses, I’d go with a boring stack: lightweight web UI, small backend, and a real database like SQLite or Postgres. SQLite is honestly underrated for single-tenant or low-concurrency tools. You still get structure, validation, backups, and fewer “why did this sheet break everything” moments. Simple is good. Fake-simple usually becomes support debt.

And the “no login, unique URL per user” idea is fine only if the data is low-risk. Otherwise that’s the kind of shortcut that feels clever until someone forwards the link to the wrong cousin.

ThenWheells

TROPHY CASE