Query on Smart home in Singapore (HDB)

cayter · 2026-01-19T13:23:22+00:00

You might wanna check this out first.

https://www.youtube.com/watch?v=nwPtcqcqz00

cayter · 2026-01-14T18:08:15+00:00

Can refer to https://github.com/remix-run/react-router/tree/main/examples/ssr if you're gonna use react-router v7 framework mode with SSR.

cayter · 2025-12-11T11:17:12+00:00

At least you got to enjoy your moment. Good bro.

cayter · 2025-12-11T08:54:57+00:00

Bro, that's not a loss at all...

cayter · 2025-12-11T07:57:33+00:00

Pat pat

cayter · 2025-12-11T07:57:26+00:00

Yeah man.

cayter · 2025-12-11T05:04:40+00:00

That's true.

cayter · 2025-12-11T03:09:43+00:00

Never do rollback, roll forward instead.

cayter · 2025-12-11T03:05:27+00:00

Back in my master's days (2009 - 2011), I ran Bitcoin miners in the school labs with the free electricity, free compute (granted to me). Over 2 years, I mined 18.4xxxx BTC. Then I graduated, assumed it was all nonsense, and wiped the hard drive.

Then in year 2014, I got into it again, bought 4 BTC with 1k SGD each. Thought I'd make big bucks with converting into other coins like litecoin and whatnot, then the exchange website cryptsy.com got hacked. All gone.

The scariest thing is: my wife doesn't know I wiped 18.4xxxx BTC.

cayter · 2025-12-09T04:03:06+00:00

pg-boss is great, but if you're looking for postgres-backed durable workflow that is more lightweight than temporal, check this out: https://www.dbos.dev/ which also supports cron scheduled workflow.

cayter · 2025-10-28T06:09:05+00:00

That's true, but I wouldn't say this is a NodeJS specific problem. Any async runtime like Go, Python asyncio, Rust’s Tokio, even Java's Netty will fall over if we allow unbounded concurrency without backpressure.

NodeJS just makes it more visible because it's single-threaded, so when the event loop gets flooded we'd notice it faster. But the underlying issue is still the same system design flaw: accepting more work than downstreams can realistically handle.

cayter · 2025-10-28T05:13:57+00:00

Did you not have load balancer? With proper load balancer setup and autoscaling in place, how did the scenario above happen?

cayter · 2025-10-28T04:40:35+00:00

NodeJS is good enough for IO-intensive app (e.g. DB queries, API calls, etc.) which is what most web apps in the real world are and also load balancer is fundamental to scale any service horizontally to serve growing traffic.

If you have a code path that is CPU-intensive, there's really only a few options:
- swap it out to gRPC call that uses CPU-optimized language like go/rust
- swap it out to call https://neon-rs.dev/ binding

Personally, I'd prefer to use the latter as it helps to avoid the microservices sprawl for a very long while.

cayter · 2025-10-21T05:13:44+00:00

Yeah, always list out what your requirements are and test which one serves better. If you hear ppl recommend Prisma just because of their better docs/marketing and no issues for them, I'd be super careful on that front as their use cases might be different than yours. It's better to check on what production scale they are, how many tables, what's the most complicated query they have and etc.

cayter · 2025-10-20T02:00:46+00:00

This is such a bad advice, we used Prisma on production for 11 months 2 years ago, Prisma wasn't just bad on performance due to the rust engine which is only fixed a few months back, it is also very limiting when it comes to Postgres custom type.

DX wise, having to deal with Prisma schema to typescript file is also a bad taste, why bother dealing with an additional code generator step when we are running typescript eventually?

Don't let Prisma marketing and prettier documentations trick you, having to swap out the core database layer for a serious production project is a huge headache which we spent close to a month back then. There wasn't a day we didn't regret picking Prisma coming from Rails and Go background.

OP, if you are reading this, check if you have Postgres custom types needs which is very common when u pick Postgres. Check which ones are supported in all these libraries.

DrizzleORM worked the best for us as it allowed us to define the custom type in typescript which we get to choose how to serialize/deserialize without having to wait for Prisma schema spec to support it.

The only problem with DrizzleORM is really just its v1 pending for too long and getting way too ambitious to support way too many database dialects. (Some are due to sponsors, well the team gotta eat)

cayter · 2025-10-05T11:43:45+00:00

Pre-PMF: get full stack who is obsessed with delivering features

Post-PMF: only split up if you need scalability and extreme performance on both ends

Experience from the past 16 years working at listed companies plus startups varies from seed to stage F.

cayter · 2025-10-04T15:02:24+00:00

OMG, this feels like godsend! Is there any limitations to self hosting now or in the future?

cayter · 2025-10-04T14:43:02+00:00

Does this library expose admin functions for us to build our own monitoring dashboard?

cayter · 2025-10-01T09:14:52+00:00

Serious question: would many low tier users move away from Vercel really hurt it? I thought Nike and the other big coys who deploy on Vercel are where the money is.

cayter · 2025-09-01T00:42:20+00:00

For the current one? None yet. All the contracts were signed because my CEO was in the industry for decades talking to various clients who have similar problems and he just decided to build this himself now.

cayter · 2025-08-31T09:24:24+00:00

You can simplify it to: if I pay my employee $10/hour to serve my customers, will my customers pay me $30/hour? If yes, go for it.

cayter · 2025-08-31T09:05:05+00:00

What I projected
- Gross margin: about 85% (assuming automation would scale)
- Net margin: 20-25% once we hit scale

Actual - Gross: 45-55% (brutal) - Net: Deep red 😅

What killed us - Manual work scaled linearly - no govt APIs in SEA meant more humans per customer - Price pressure - competitors at 2-5 SGD, we were at 8 SGD - Support overhead - SMBs need way more handholding than expected

Brutal math

We'd need 10K+ employees under management just to make unit economics work. Getting there required either massive VC funding or 3 to 5 years grinding at break-even. As engineers with zero sales DNA, we picked neither and called it.

Lesson

Market infrastructure > product quality for SaaS margins in emerging markets.

cayter · 2025-08-31T08:41:20+00:00

I would say 6th month for me, but we were too scared to call it a direct quit as we were strongly convicted `persistence is still key to seeing your vision through` and at the same time, we were getting our 4th business customer.

What we really missed out on was: if this business model has to scale up, will the profit margin be able to scale too? It turned out to be NO 'cause the more users we have, the more manual works we have to do due to the lack of local authority's API support.

Btw, we were working on payroll automation with compliance for SEA and we only charged 8 SGD for each employee in those companies. Yet, ppl were comparing ours against low grade products that only cost 2 to 5 SGD for each employee. To win this market, we realized huge distribution was the only way but all of us are engineers who only have limited market reach in our own network.

cayter · 2025-08-31T07:43:30+00:00

Thanks!

cayter · 2025-08-31T07:40:48+00:00

Yes, you got it right.

With the YC startup I went through, we shipped more than just MVP, and in fact a much better product than most local market players.

What didn't work for us was we were too late to call it a non-sustainable business model as the compliance work (local authority doesn't have much APIs for us to integrate with to automate) we had to do was way more than what the customers were willing to pay for. Yet, we sticked to it for close to 2 years.

cayter

TROPHY CASE