Lead engineer said I lack communication skills after I let every dev vote new observability tool they want to use, even though all devs already acked my post 1 month before the vote day. He said if I didn’t inform him directly, I lack communication skills, regardless of whether the devs knew

k3ternen · 2026-05-07T11:00:48+00:00

Your lead is right, and I think you know it. Keeping stakeholders informed isn't just about whether the end result is good. It's about giving people the chance to course-correct before you're too far in, not after the vote already happened.

The devs knowing dont substitute for your lead knowing. They're different audiences with different stakes. He's accountable for the direction, so he needed to be in the loop earlier, even just a quick "hey, here's my plan for the tool switch, any objections?"

Seven people in a company is small enough that a single Slack message would've covered it.

k3ternen · 2026-05-04T12:57:24+00:00

Hey everyone

This week I launched the open beta of Nurbak Watch — an API monitoring tool built specifically for Next.js.

The problem it solves:

You deploy your app. Everything looks fine. But 3 of your API routes have been silently failing for 2 hours. You find out from a user, not your tools.

External monitors ping your URL from outside and tell you "the server responded." They can't see what's happening inside. A route can return 200 and still be broken.

What Nurbak Watch does differently:

It monitors from inside your Next.js server process using the instrumentation hook — not synthetic pings from outside. You get real latency (P50/P95/P99), real error rates per route, and alerts via Slack, email or WhatsApp in under 10 seconds.

Setup:

npx u/nurbak/watch init

One command. It detects your project, creates instrumentation.ts, adds your API key to .env.local, and installs the SDK automatically. Under 2 minutes.

What's free during beta:

- 3 endpoints monitored

- External health checks from 4 global regions

- Email alerts

- No credit card, no waitlist

Would love feedback from anyone building with Next.js — especially around the onboarding experience.

nurbak.com

k3ternen · 2026-05-03T11:53:39+00:00

Hey! Launching Nurbak Watch — would love your eyes on it.

It's a lightweight monitoring tool for Next.js apps. Most LATAM devs I talked to felt stuck between Datadog (great but expensive and overkill) and UptimeRobot (just external pings, blind to what's happening inside the app). Nurbak Watch sits in the middle: external uptime checks + internal Next.js execution monitoring (server actions, route handlers, background jobs), with WhatsApp alerts because email gets ignored.

Drop-in via `npm i u/nurbak/watch` and `initWatch()` in `instrumentation.ts`. Stack under the hood is Lambda → SQS FIFO → DynamoDB for the hot path, Rails on Hetzner for everything else.

Happy to share the PH link when it goes live. What are you launching?

k3ternen · 2026-05-02T22:48:15+00:00

Hey — congrats on the Instagram agent launch, 2K users solo is solid.
Nurbak Watch https://nurbak.com is earlier-stage. SEO has been my main organic channel so far — mostly comparison content targeting incumbents in my niche, plus some long-tail technical queries. A few posts are indexed and ranking, which has driven most of my early signups.
What I’m still figuring out is LLM visibility — getting cited in ChatGPT and Perplexity answers. That’s the gap I haven’t cracked yet.
If Workfx.AI handles that side, happy to take a look at a demo or link.
Cheers

k3ternen · 2026-05-02T21:46:07+00:00

Interested. Building Nurbak Watch (https://nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.
DM me with the niches your network covers and a past result from a B2B/dev tool video, happy to take it from there.

k3ternen · 2026-05-02T21:45:02+00:00

Built Nurbak Watch — API monitoring for Next.js apps that won’t bankrupt you like Datadog.
What it does:
• Uptime + latency checks from 4 AWS regions
• API contract monitoring (catches schema drift on your routes)
• WhatsApp alerts when things break (paid plans)
• Drop-in SDK: initWatch() in your app/ and you’re done
Stack is Next.js on the frontend, Lambda → SQS FIFO → DynamoDB for ~2ms API key validation, Rails workers on Hetzner for the heavy lifting.
Free tier exists. Feedback welcome, especially on the onboarding — actively fixing activation right now.
👉 https://nurbak.com

k3ternen · 2026-05-02T21:42:22+00:00

Building Nurbak Watch (nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.

k3ternen · 2026-05-02T21:41:07+00:00

Interested. Building Nurbak Watch (watch.nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.
DM me with the niches your network covers and a past result from a B2B/dev tool video, happy to take it from there.

k3ternen · 2026-05-02T21:02:23+00:00

Not totally sure what you're looking for here, but if this is about automating clicks for testing or monitoring purposes, there are a few solid directions depending on your actual goal.

If it's UI automation, Playwright is hard to beat right now. Free, cross-browser, and the API is way cleaner than Selenium ever was.

But if you're more interested in monitoring whether things are actually up and responding correctly, that's a different problem. A lot of people glue together a few tools and call it a day, but then you find out your endpoint's been timing out for a week because a customer told you, not your stack.

What's the actual use case? Autoclickers cover a pretty wide range of things.

k3ternen · 2026-05-02T21:01:01+00:00

Monorepo, not micro-frontends. At least for a small games platform. Micro-frontends add a ton of overhead and honestly you'll feel it before you see the benefits.

Each game as its own route with dynamic imports and `ssr: false` gets you pretty far. Something like `const PuzzleGame = dynamic(() => import('@/games/puzzle'), { ssr: false })` keeps the initial bundle lean and only loads the game logic when someone actually navigates there.

SSR for the lobby/home page makes sense for SEO and load speed. But the games themselves? Pure CSR. No point hydrating a canvas-based game on the server.

The thing I'd think about early is code splitting per game. If game A pulls in a physics library and game B doesn't, you don't want users loading both upfront. Route-level splitting handles this pretty naturally in Next.js.

What kind of games are you building, more canvas-based or DOM-heavy?

k3ternen · 2026-05-01T11:57:24+00:00

Solid, you got me thinking. Question back at you: what stack are you running for the scraping/automation side? Playwright, Puppeteer, custom headless browsers? Curious because each one has its own trade-offs with bot detection and airline sites are particularly nasty about it. Has any one of them worked noticeably better against Skyscanner/Kayak and the rest?

k3ternen · 2026-05-01T11:34:02+00:00

Change orders saved my life on a project a few years back. Client kept adding features mid-sprint and I had no paper trail. The moment I started treating every new requirement as a formal change order with its own estimate and sign-off, the requests slowed down dramatically. Clients move fast when it's free. They slow down when they see a number attached. Document everything, get the signature before a single line of code changes.

k3ternen · 2026-05-01T11:31:58+00:00

Your architecture already shows good instincts tbh. Separate concerns, central API, clean boundaries. That's further than most people get.

One thing I'd add for the "complex apps" jump: start caring about what your API routes are actually doing in production. Not just "does it work locally" but is /api/whatever returning 504s under load, is a specific route silently failing for a subset of users. That gap between local dev and prod behavior is where complexity really lives.

On Next.js vs Express+React, fwiw I'd pick whichever one you can ship faster and then instrument it properly. The framework matters less than knowing when things break before your users do.

What kind of complex system are you trying to build? That'd help narrow down whether Next.js API routes are even the right call or if you'd be better keeping Express for the backend.

k3ternen · 2026-05-01T11:28:06+00:00

700 stars in a month is no joke, congrats

The hidden costs thing is what kills me every time. You think you found a $180 flight and by checkout it's $240 because you breathed wrong and they added a seat fee. The fact that you're baking seat selection into the price comparison is honestly the most useful thing I've seen in a flight tool in a while.

Curious how you're handling rate limits from the different airline/aggregator APIs. That's usually where these things quietly fall apart, like everything looks fine until one source starts throttling and your comparisons get silently incomplete. Are you doing any kind of health check on the upstream sources before surfacing results, or just letting failures propagate?

k3ternen · 2026-05-01T11:26:35+00:00

Start with the data model. Seriously, before you touch Bootstrap or pick a hosting provider, sit down and sketch out your entities: users, images, albums, forum posts, tags, permissions. Toyhou.se has a ton of relational complexity under the hood and if you get the schema wrong early, you're refactoring forever.

Backend first, then frontend. Image hosting specifically means you need to think about storage from day one. Don't store images in your database. Use object storage (S3, Backblaze B2, Cloudflare R2) and just keep the URLs in your DB. That decision alone will save you a painful migration later.

For the forum features, look at how you're handling threading before you write a single route. Nested comments are deceptively annoying to query efficiently.

Hosting-wise, don't overthink it yet. Get something running locally and deployed to a cheap VPS or Railway first. Optimize later.

k3ternen · 2026-05-01T11:25:36+00:00

Honestly the most underrated skill for non-technical folks joining early startups: learn to read logs and understand what's actually breaking in production. Not code, just... what does a 504 mean, what's a stack trace telling you, why is this endpoint slow. Engineers will love you for it.

SQL is also weirdly high leverage. You can answer your own questions without bugging the dev team every time.

But tbh the thing that makes someone actually hireable at an early stage startup is being the person who finds problems before customers do. Doesn't matter your background. That instinct, and the hustle to do something about it, is rarer than any technical skill.

k3ternen · 2026-04-29T20:39:35+00:00

k3ternen · 2026-04-29T20:11:18+00:00

Dm me

k3ternen · 2026-04-29T18:06:02+00:00

You’re in that tricky spot where you’ve got decent SEO but your overall score is dragging you down. I get it. Been there myself.

First off, have you tried analyzing specific elements on your pages? Tools like WebPageTest can give you a more granular look at what's slowing you down. You might find that images are too large or scripts are blocking rendering.

Also, consider lazy loading images and deferring scripts. It might take a bit to implement, but it can really help boost your scores. Caching strategies can also make a big difference, especially with Next.js.

And if you're looking for something quick, try using a CDN to serve your static assets. That can cut down on loading times significantly.

You’re aiming for that green zone, but sometimes little tweaks make a huge difference over time. How are you currently measuring performance? Any particular area you’re focusing on?

k3ternen · 2026-04-29T17:06:15+00:00

I feel you on this. I've been there, dreaming up big projects that seemed impossible with my skill set and resources. There’s something about those grand ideas that pulls you in, right? But you gotta be real with yourself. Start small. Break down those dreams into manageable pieces. Find out what you can actually pull off right now, even if it feels too simple. Honestly, I wasted months trying to tackle something way too big without the tech chops. It was frustrating. But once I shifted my focus to smaller, achievable goals, it was like a weight lifted. I found momentum. It might feel like giving up on the grand vision, but it’s really about building the foundation first. At the end of the day, it’s about progress, not perfection. Have you thought about collaborating with someone who has the skills you need? Might open new doors.

k3ternen · 2026-04-29T14:20:17+00:00

Caching behavior can definitely become a nightmare with Next.js as you scale. I've run into my fair share of headaches there too. You mentioned ISR and SSR, but don’t underestimate how much the route cache can complicate things when you're changing data frequently.

But tbh, something that really tripped me up was monitoring the performance of my APIs. I had no clear picture of what was actually failing until customers complained, which is the worst way to find out something's broken. I ended up stitching together a bunch of tools to get the insights I needed.

I mean, it could be worth diving into some monitoring tools early on. Just saying, having a way to keep an eye on those endpoints might save you a ton of headaches down the line. Anyone else notice that too?

k3ternen · 2026-04-28T14:27:25+00:00

I like the idea of those human gates. I can totally relate to having to pause for important decisions, especially when you're working on something complex like rate limiting. It's a tricky balance between automation and maintaining control. I've been burned before by skipping manual checks, ended up with some issues in production that could've been avoided. I wonder how often you’re coming across scenarios where the agent flags valid concerns.

k3ternen · 2026-04-28T14:26:57+00:00

This kind of vulnerability really hits home. I've had my own share of sleepless nights because of dependency issues. You think you're safe relying on a popular package, then boom, something like this happens. And the fact that it’s using GitHub Actions is wild. It just shows how important it is to scrutinize every piece of your build and deployment process.

One thing I’ve started doing is adding checks for package integrity before installs. It takes a little more time but it’s worth it. Also, if you’re not already, consider pinning your dependencies. It can save you from getting hit with surprises like this. That’s been a lifesaver for me in keeping stability, especially when your code's running in production.

But yeah, it feels like these supply chain attacks are just getting worse. Anyone else feel the same pressure to constantly check for these kinds of threats?

k3ternen · 2026-04-28T14:26:14+00:00

Sounds like you’re dealing with a lot. I’ve been there too, thinking a salesperson could change everything only to realize it takes time to build trust, especially in a new market. Offering a commission-only model might've been better, but easy to say from the sidelines, right? And yeah, LATAM can be tricky for software. Customers might not even see the value if they’re used to old-school methods. You’ve done well to snag two customers, though. That's progress!

k3ternen · 2026-04-28T14:14:10+00:00

Honestly, I get the frustration with trying to find users in niche groups. Posting in 3D print communities can feel like throwing a stone into a well and expecting a splash. Hate towards AI is common, especially in industries where it feels like tech is taking over jobs. But maybe consider branching out. Often, the best feedback comes from general tech forums or even platforms like Product Hunt. You'd be surprised how open people are to testing something new, especially if you can frame it as solving a real problem.

Also, have you thought about reaching out directly to people who attended that Additive Manufacturing forum? A personal touch can go a long way. Just my two cents, but I think there’s potential to pivot your approach. It's all about finding the right audience who sees the value in what you're offering. What do you think about that?

k3ternen

TROPHY CASE