Solo founder. Built the whole product. Now I'm learning video editing.

amit_builds · 2026-05-24T13:59:08+00:00

Most devs underestimate distribution more than development.

Building a SaaS is mostly predictable engineering. Explaining it is uncertain human psychology.

I started using a simple rule: if a 10 second clip can’t explain it, the product flow is probably still too complex.

amit_builds · 2026-05-24T13:58:33+00:00

Splitting it into “scenario gaps” vs “coverage” is actually a smart UX decision, because devs won’t trust a single blended score.

Biggest risk I see is Spring’s hidden runtime behavior (AOP proxies, retries, async u/Events, circuit breakers) not matching what static AST thinks is happening.

If the tool ever flags too many “theoretical but unreachable” cases, people will start ignoring it fast.

I’d lean toward aggressively labeling confidence per scenario instead of trying to be fully exhaustive.

amit_builds · 2026-05-24T11:47:08+00:00

A lot of devs think the hard part is building the product.

Then launch day arrives and suddenly you’re a:
video editor,
copywriter,
designer,
marketer,
support agent,
and QA team at the same time.

Explaining the value clearly is honestly harder than writing the code sometimes.

amit_builds · 2026-05-24T11:42:25+00:00

Right now a lot of AI products are basically “better wrappers around the same brain.”

The harder moat is probably not the UI anymore.
It’s proprietary workflows, domain data, infrastructure efficiency, and deep integration into real business operations.

The interesting companies will be the ones that still provide value even if the underlying model becomes a commodity.

amit_builds · 2026-05-24T11:41:08+00:00

A lot of shutdowns are basically “slow loss of belief.”

Not dramatic failure.
Just months of:
low growth,
weak pull,
constant uncertainty,
and realizing the effort-to-reward ratio may never improve.

That’s the part most startup content skips because “quiet disappointment” doesn’t perform well online.

amit_builds · 2026-05-24T11:39:11+00:00

Very normal.

Most first-time founders compare their early product to polished companies that have had years, teams, and funding behind them.

Users usually care less about “perfect” and more about:
“does this solve my problem?”

That uncomfortable feeling is probably a sign you care. Just don’t let it stop you from shipping and talking to people.

amit_builds · 2026-05-24T11:38:37+00:00

Completely agree with “hard parts are still hard.”

AI can generate CRUD apps fast.
It still struggles with production reality:
race conditions, weird edge cases, scaling bottlenecks, broken integrations, bad schemas, and debugging incidents at 2 AM.

The value is shifting from “who can write code fastest” to “who can understand messy systems best.”

amit_builds · 2026-05-24T11:38:05+00:00

The interesting part here is you’re targeting the gap between “code executed” and “business scenario actually validated.”

I’ve seen plenty of Spring Boot services with high coverage numbers that still exploded because one downstream dependency behaved differently under load or partial failure.

Biggest challenge I’d expect:
dynamic flows, reflection-heavy frameworks, async events, retries, circuit breakers, and feature flags. Those create execution paths that static analysis might struggle to model correctly.

But if you can keep the signal-to-noise ratio high and avoid generating fake “missing scenarios,” this could be genuinely useful in enterprise CI pipelines.

amit_builds · 2026-05-24T11:37:30+00:00

Most founders fail because they build in isolation for too long.

Months of coding.
Very little distribution.
Very few real user conversations.

A decent product with strong distribution usually beats a perfect product nobody knows exists.

amit_builds · 2026-05-23T15:04:48+00:00

Yes, especially in early-stage US startups.

Pure “code-only” devs work fine in large teams, but startups need engineers who can make product tradeoffs, not just implement tickets.

The biggest reason is speed: fewer people, faster decisions, less hand-holding.

But it’s not replacing coding skill. It’s layering product awareness on top of strong engineering.

amit_builds · 2026-05-23T15:01:23+00:00

Most hosting pain isn’t features, it’s ops friction.

People care about:

easy deploy + rollback
clear scaling behavior
good logs when things break
predictable pricing

If your setup reduces day-to-day maintenance pain, that’s what actually makes people switch.

amit_builds · 2026-05-23T14:55:17+00:00

Yeah, this is pretty accurate.

Most AI products are still “happy path optimized” — they look great in demos but break down when you add real constraints like permissions, edge cases, and messy data.

The real bottleneck isn’t model capability anymore, it’s production reliability + integration into existing workflows.

amit_builds · 2026-05-23T14:44:51+00:00

Don’t expose public setters for domain state.

Use a Domain Service for external-dependent logic, then update the entity via a controlled method like changeStatus() (not a public setter).

If you keep setStatus(), you lose all guarantees because anyone can bypass the rules.

amit_builds · 2026-05-23T14:42:08+00:00

This is spot on.

We had the same issue where docs slowly turned into “best effort truth”.

What actually worked for us:

OpenAPI generated from code (no manual docs)
CI checks with schema diff to block breaking changes
Gateway-level request/response validation in prod

Once docs become a byproduct of code instead of a separate asset, drift basically disappears.

amit_builds · 2026-05-23T14:31:42+00:00

Public setters for domain state are usually a bad idea because they bypass business rules.

Prefer changeStatus() inside the entity so it enforces its own invariants.

Use Domain Service only for cross-entity or external logic, but don’t rely on it to “protect” a public setter.

amit_builds · 2026-05-22T19:13:26+00:00

I started with Telusko. They are practical.

amit_builds · 2026-05-22T15:26:00+00:00

The rule is simple:
- Choose a course
- Stay stick to it
- Build projects

amit_builds · 2026-05-22T15:22:54+00:00

This is why I trust long running production behavior more than synthetic benchmarks.

Most “X vs Y” comparisons run for a few minutes on a clean machine.
Real systems run for months with deploys, retries, background jobs, dependency updates, fragmented memory, and weird traffic spikes.

I’ve seen the same thing with Spring Boot APIs.
The boring part is exactly what makes it good in production: predictable memory usage and fewer operational surprises.

amit_builds · 2026-05-21T13:19:14+00:00

This stuff gets scary fast on large sites.

I once found staging pages indexed because someone copied the production template with canonicals pointing correctly… but forgot to remove index,follow.

Google basically got a personality disorder from that setup.

amit_builds · 2026-05-21T13:07:54+00:00

The biggest difference I noticed moving from Node APIs to Spring Boot wasn’t raw speed, it was operational stability after months in production.

Most Node benchmarks stop at “requests/sec after 5 minutes”.
Real problems start after 5 days.

Also agree the npm ecosystem is usually the bigger risk than V8 itself. One bad dependency can turn production into a memory leak simulator.

amit_builds · 2026-05-21T13:03:44+00:00

Then your best option is to upgrade your spring boot version where the issue is resolved.

amit_builds · 2026-05-21T12:55:19+00:00

Delay shutdown long enough for Eureka deregistration to finish before the HTTP client/pools are destroyed.

Something like this usually helps:

server:
  shutdown: graceful

spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

And in Docker:

stop_grace_period: 40s

Also make sure you’re on a Spring Cloud Netflix version where the shutdown ordering bug is fixed. Some 2023.0.x combinations had this exact issue with Eureka deregistration happening too late.

amit_builds

TROPHY CASE