Gabriel

Hiring a contractor in Latam has boosted our shipping speed by 30-40% Here's the story: I was so against hiring a contractor cuz of a shitty experience I had with one while at my corporate SWE job. He was super lazy and only finished 1 ticket in 3 months. It gave me a terrible impression of contractors for the longest time. I forgot that they fall onto the same bell curve of competence as the rest of humanity ... most of them suck at their job, some are decent, and some are great. Flash forward, 2 months into the hiring process for our full-time engineer at Nero, and I'm frustrated with the inaction we're succumbing to ... I just want projects DONE. So, I decided to hire a contractor in the meantime. A few weeks into it, here are my thoughts - He isn't a CMU or MIT grad, I can't trust him fully with shipping features end-to-end ... But he can take features that I've been dreaming about to 80% completion. And that makes all the difference between a product that stays stale and a product that's constantly improving. Not sure if I'll keep him after I hire a full-time eng, but it's the best $5,000 I've spent in the eng org so far.

So Nero's come a long way since November. We now have 650k MAU and paid out over $3.5M to artists. But it's not the most robust system yet -- with this kind of traffic, our current queue architecture won't hold up forever. I knew it's gonna break but I wasn't sure when or where the breaking point was. Like ... - how many submissions / sec can we handle? - how large can sessions get before it lags? - how many connections can each session handle? So instead of waiting, I decided to break it myself! I built a stress testing suite with artillery that slams our staging app (which has same resources as prod). But that was basically a black box - so I added timers to everything. These tracked the ms duration of every important action taken -- DB writes, Redis mutations, web socket broadcasts, etc. So the plan was simple -- slam our server with scaling submission speeds + connections and watch what breaks first. And it worked really well :D We don't have to guess when or how our system will break anymore! And based on our historic growth, we can estimate how many months we have before a refactor is necessary woohoo

you realize you can negotiate with them right? they took significantly less than that from our company, even when we were below $50k MRR surprisingly, they really want to keep startups from jumping to other payment processors

fun fact: at $50k MRR, you pay Stripe $17k a year

Sup x im backkkkk 💅 I feel like posting about random technical shit again!!

@rrhoover help artists make money on livestreams by listening to their fans music. nero.fan

I'd love to invest in more founders building something weird in consumer. If that's you, shoot me a demo or link to the product. My DMs are open. :)

I really want to buy this wine red Les Paul. But I'm still saving up for it. So instead, I used Gemini to will it into existence. It generated me with symmetrical features, lower BF %, sharper jawline, curlier hair AND with my dream guitar AND in a cool lil living room playing it. I always thought visualization / goal setting was cringe af but some of it is actually backed by research ... sooo new target acquired?

I used @claudeai Opus 4.5 to generate architecture and sequence diagrams and the results were incredible. I used to spend days making shitty visuals at my previous SWE job. This is an underrated use case for LLM dev.

I'm hiring a founding engineer at nero.fan! Offering $140k-180k + equity for in-person SF. We're working on really cool technical problems AND helping creators make money on livestreams. nero.fan/careers

Gemini 3 Pro is cracked. Antigravity (new google IDE) is decent too but I'm only really using it cuz it's free and gives instant access to Gemini 3 that I can't get on Cursor. @cursor_ai is hella slow during peak hours rn for all models, been frustrating.

Dependency injection (DI) has consumed my life for the past 2 days. I first learned about it in a unit testing book and remember thinking "there's no way people actually architect systems like this" Well you might be asking... wtf is DI? It's just a fancy shmancy CS term for giving an object its instance variables. In our case, our express app has external dependencies like redis, prisma, queue, and a logger. Right now, those objects operate as singletons - we create them once and import them wherever we need them. Super easy developer experience. Naturally, you ALSO might be asking... why would I ever want to complicate that? Cuz for unit tests, we don't want OR need the real queue or logger - we want fake versions (called mocks/stubs) so we can test our app logic and that ALONE. But for integration tests, we DO want the real versions - after all, that's what integration tests are for. If our code just imports its dependencies, we end up making it really difficult to be like "hey for this unit test use a fake version of the queue, but for this other integration test, use the real thing" So the DI approach = pass the classes in via constructors instead. Now swapping between real and fake versions is trivial. Can't wait to struggle in refactoring hell for the next week, yay!

Been trying to figure out how to horizontally scale WebSocket servers recently. It's been an interesting problem to work on, here's are my thoughts + learnings. The problem: having 1 server works for us now, but I see it as a weak point in our system. I've scaled it vertically to 32gb of memory and 32 vCPUSs which is extremely generous, but having 1 point of failure leaves us vulnerable to an outage if anything goes wrong and crashes that server. So, it makes sense to get ahead of this problem and add more servers! BUT our sessions operate via WebSockets -- which means we need to figure out a way to ensure data synchrony between servers cuz state is stored locally on each machine rn. Take this example -- if a streamer is connected to Server A and a fan connects to Server B and submits a song, Server A has no way of knowing that ... only the database and the state and users on Server B are updated. So, we need to figure out a way to make sure all servers rely on the same session state ... *cough* Redis *cough* A common approach is the pub/sub design pattern with Redis. That means when Server A mutates the state, it publishes a message and Server B subscribes and applies the delta to its local state. Seems great at first, but it introduces a lot of complexity -- messages can get missed, leading to state drift, and conflicts can get weird. Something simpler would be to just create a shared state cache -- just store the session state directly in Redis and have each server update that state. So that (a shared state) + the Socket Redis adapter (auto-publishes messages between servers) + distributed locks (prevents conflicts) means that we ensure the state is the SAME between all servers at ALL times. So there it is. There's my master plan to horizontally scale our WebSocket servers. Hope that wasn't too boring for you plebs.

@tiffanyyan_x i was so ready to leave nyc for SF after a year

If you were ever debating between SF or NYC, just remember: People in SF want to move to NYC, but people in NYC don’t want to leave for SF. I’m a city person, so I’d choose to live in NYC over SF. The SF weather and the proximity to water is great though. Plus my friends are there. That’s a big factor.

Just got an offer for 40% higher TC as a SWE at an NYC health tech I rejected it instantly. I'm only 22 once and the risk I'm taking on Nero is worth it. Don't have the patience for golden handcuffs for another 1-2 years. That said, definitely taking this as a positive career signal that's boosting my self-worth as an engineer.