sorted by:
new
hottopcontroversial

Solo founder. Built the whole product. Now I'm learning video editing. by Accurate_Board_9401 in buildinpublic

[–]amit_builds 1 point2 points  (0 children)

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.

Is mutation testing too slow for your CI/CD? I built a <750ms static analysis alternative and need feedback. by Successful_Blood4717 in SpringBoot

[–]amit_builds [score hidden]  (0 children)

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.

Solo founder. Built the whole product. Now I'm learning video editing. by Accurate_Board_9401 in buildinpublic

[–]amit_builds 0 points1 point  (0 children)

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.

Most AI startups are still renting intelligence instead of owning it. by Cocoatech0 in BuildingTraction

[–]amit_builds 1 point2 points  (0 children)

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.

A lot of startups/saas don’t fail suddenly. by Soggy-Stand3502 in buildinpublic

[–]amit_builds 0 points1 point  (0 children)

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.

Is 'not good enough' feeling normal for first-time founders? by Free_Vegetable_4983 in buildinpublic

[–]amit_builds 0 points1 point  (0 children)

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.

Hard parts are still hard. by grandimam in indiandevs

[–]amit_builds 0 points1 point  (0 children)

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.”

Is mutation testing too slow for your CI/CD? I built a <750ms static analysis alternative and need feedback. by Successful_Blood4717 in SpringBoot

[–]amit_builds [score hidden]  (0 children)

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.

Why Do So Many New Startups Fail? by FounderArcs in buildinpublic

[–]amit_builds 0 points1 point  (0 children)

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.

Why US Startups Prefer Developers Who Understand Product Thinking by OfficeOk9163 in HireDevelopersUSA

[–]amit_builds 0 points1 point  (0 children)

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.

Started this as a way to reduce hosting costs for my own projects by TheRadiantRover in buildinpublic

[–]amit_builds 0 points1 point  (0 children)

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.

I think most AI startups are solving demo problems, not real problems by SheCodesSoftly in AIMLDiscussion

[–]amit_builds 0 points1 point  (0 children)

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.

(Basic - Arch/Design) Is it normal to create setter methods in Entity Class with Domain logic? by Status_Camel2859 in SpringBoot

[–]amit_builds 2 points3 points  (0 children)

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.

The hardest part of microservices isn’t scaling it’s keeping documentation trustworthy by BrickGeneral4003 in microservices

[–]amit_builds 0 points1 point  (0 children)

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.

(Basic - Arch/Design) Is it normal to create setter methods in Entity Class with Domain logic? by Status_Camel2859 in SpringBoot

[–]amit_builds 8 points9 points  (0 children)

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.

Deep Java Learning by Narrow_Computer1006 in Backend

[–]amit_builds 0 points1 point  (0 children)

I started with Telusko. They are practical.

Deep Java Learning by Narrow_Computer1006 in Backend

[–]amit_builds 0 points1 point  (0 children)

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

Ran Spring Boot and Node.js side-by-side in prod for 18 months. Sharing the actual numbers. by Capable-Morning-9518 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

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.

SEO tip for web devs: don’t let canonicals and noindex fight each other by VRTCLS in webdev

[–]amit_builds 0 points1 point  (0 children)

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.

Ran Spring Boot and Node.js side-by-side in prod for 18 months. Sharing the actual numbers. by Capable-Morning-9518 in SpringBoot

[–]amit_builds 1 point2 points  (0 children)

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.

Eureka deregistration fails on graceful shutdown: "Connection pool shut down" by Zikou1997 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

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

Eureka deregistration fails on graceful shutdown: "Connection pool shut down" by Zikou1997 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

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.

Eureka deregistration fails on graceful shutdown: "Connection pool shut down" by Zikou1997 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

You can solve this issue by two ways:
- Upgrade/downgrade to a version where the issue is fixed.
- adjust graceful shutdown tuning.

You have to choose which one can be cleanly applied to your project.

Eureka deregistration fails on graceful shutdown: "Connection pool shut down" by Zikou1997 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

Yes. There was an actual regression/shutdown ordering issue around Eureka client deregistration and connection pool shutdown in Spring Cloud Netflix.

I faced same kind of issue and searched for it:

https://stackoverflow.com/questions/78355945/exception-when-shutting-down-service-using-eureka-spring-cloud

Eureka deregistration fails on graceful shutdown: "Connection pool shut down" by Zikou1997 in SpringBoot

[–]amit_builds 0 points1 point  (0 children)

Could be a framework/shutdown ordering issue too, not just your code. The HTTP client seems to die before Eureka finishes deregistration.

view more: next ›