u/alexstrehlke

Whether B2C/B2B, pre ycombinator or post, how have people decided that yes, the product you are making is something worth buying?

Is it simply taking a chance, or more of a matter of market validation tests? Curious how people approach this.

There is something genuinely unhinged about the mental state that kicks in during AP season where you finish an FRQ with like two vague sentences and a diagram you drew wrong and walk out thinking "honestly that was pretty solid."

Not even in a cope way. In a fully committed, I-have-convinced-myself way. You're in the parking lot telling your friend "I mean I got the main idea across" and you both know that's not true and nobody says anything.

And the thing is it's not really denial. It's more like your brain runs a real-time cost-benefit analysis and decides that believing the answer was fine is genuinely more useful than knowing it wasn't. Which, honestly, respect. That's a form of intelligence.

The flip side is somehow worse though. You studied, felt okay going in, and then spend the whole car ride home catastrophizing about one multiple choice question you probably got right. That one doesn't have the same charm.

AP season just breaks your ability to assess anything accurately. You're running on four hours of sleep and the vague memory of a Quizlet you opened once and somehow that feels like preparation. And then you pass. Or you don't. And either way you're shocked.

Does the delusion hit mid-exam for you or is it more of a post-exam thing? Also genuinely wondering whether the people who leave feeling good are actually calibrated or just better at committing to the bit.

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]

There's a version of building a dashboard where the metrics are right, the charts are clean, and it genuinely feels like something useful exists. And then there's the separate question of whether anyone actually changes what they do because of it. Those two things are not the same, and I think they get conflated a lot.

For dashboards built around personal or behavioral data, where the feedback loop is something like "you see the data, you adjust what you do," how do you actually test whether the insight is landing? Is it retention of the habit being tracked? Whether someone opens it more than once a week without being prompted? Something else?

I'm also trying to figure out how much of this is a data problem versus a design problem. If someone stops engaging with a dashboard, is it usually because the metrics were wrong, because the interface made it too effortful to extract meaning, or because the novelty wore off and the underlying behavior didn't change enough to stay interesting? Those feel like pretty different failure modes with pretty different fixes.

And on the flip side, has anyone found a pattern that reliably signals a dashboard is actually working? Something beyond open rates that gets closer to "this thing changed how someone thinks about their own data."

Most of what gets written about analytics tooling focuses on infrastructure or visualization best practices. The question of whether the thing you built actually does anything useful for the person looking at it seems genuinely underexplored. What have people found?

The cold start case keeps coming up as the messiest part of deep linking and I want to understand how people are handling it in production.

The scenario: user taps a link, app isn't running, it opens directly to the target route. But auth state needs to resolve first, and depending on how fast that happens, you're either landing somewhere that requires auth before the user is confirmed, or bouncing them through a redirect that feels janky.

With Expo Router the file-based approach handles the happy path cleanly, but conditional navigation gets complicated fast once you have protected routes. The auth check isn't synchronous and the router doesn't have a clean way to hold on that. The workarounds with loading states and redirects get the job done but feel fragile in ways that are hard to test.

React Navigation with a custom linking config is more explicit about this, and that explicitness actually helps because you can intercept before navigation happens. But the boilerplate adds up fast, especially when universal links, push notification deep links, and cold start all need slightly different treatment.

What's the cleanest pattern for cold start specifically? Is the answer just a proper loading state that blocks all navigation until auth resolves, or is there something more elegant? And does the solution differ much between Expo managed workflow versus bare?

What are people actually shipping with right now, not what the docs suggest?

Genuinely wondering how people here manage it. Between studio time, practice rooms, and everything else Berklee throws at you, finding a consistent window to work out feels like its own project. And the campus doesn't exactly have a rec center you can just wander into between sessions.

I built a free workout tracking app called Fortis: Workout Log & Tracker. It's basically a strength-focused logging tool, custom exercises, templates, RPE logging, estimated 1RM tracking over time, and the ability to share progress with friends. Still early but it works well if you're trying to stay consistent without a ton of overhead.

If you're hitting one of the YMCAs nearby or a gym in Fenway or Back Bay and want something to actually track what you're doing, give it a shot. Would love feedback from people who are fitting training around a schedule this chaotic.

Trying to think through this more carefully because the gap between "qualified on paper" and "actually getting interviews" seems way larger than it should be for a lot of people, and the explanations I keep seeing don't fully account for it.

The standard advice is: LeetCode, good resume, network, apply to a lot of places. That's all fine. But there's clearly something else going on because plenty of people do all of that and still hit a wall, while others with comparable or weaker technical backgrounds seem to get traction faster. The delta isn't always obvious from the outside.

A few things worth pulling apart here. Is resume filtering actually happening on content, or is it more about formatting and signal density in a way that has nothing to do with actual skill? And how much of the networking advice is genuinely useful versus survivorship bias from people who happened to know someone at the right time and are now attributing it to the strategy?

The thing that seems underexplored is the role of specificity in the application itself. Generic applications to a broad range of companies versus targeted applications where you've done real homework seems like it should matter, but it's hard to know if that's actually true or if volume is just the dominant variable at the screening stage.

Also worth thinking through: does the entry point matter as much as people think? Gunning straight for a big name versus getting in somewhere smaller first and moving laterally seems like a reasonable path, but the people who took that route don't seem to talk about it as much as the ones who went direct.

To be frank, a lot of the career advice in this space is written by people who made it through a particular window in a particular market and are pattern-matching backward in ways that may not hold right now. What actually moved things for people who were genuinely stuck and then weren't?

[ Removed by Reddit on account of violating the content policy. ]

This is probably obvious to a lot of people here but it genuinely shifted something for me so worth sharing.

I used to cook rice fresh every time I needed it, which sounds fine until you're tired after work and realize you have to wait 20 minutes before you can actually eat anything. Pasta I'd cook in bulk, grains I'd cook in bulk, but rice I kept treating as something that had to be made to order for some reason I can't fully explain.

A few weeks ago I just made a full pot, let it cool, portioned it into freezer bags flattened so they'd stack, and threw them all in the freezer. Now when I want to eat, rice is ready in about two minutes out of the microwave with a splash of water and it tastes basically the same. Honestly it might be slightly better because it doesn't get sticky and gummy the way freshly cooked rice sometimes does when it sits in the pot too long.

The thing that actually matters for solo cooking is that it removes the "I don't want to wait for rice so I'll just eat something worse" decision entirely. That decision was happening more than I realized.

Flattening the bags before freezing means you can fit a lot of them in a small freezer, and they break apart easily if you only need part of a portion.

What are the other things like this that seem obvious in retrospect but actually changed how you cook at home?

Went through the exercise of setting up proper S3 cost monitoring recently and honestly the gap between "metrics that look useful" and "metrics that will actually catch the thing that destroys your bill" is bigger than I expected. Figured it would be worth writing up because the AWS docs don't really surface this in a practical way.

The obvious starting point is NumberOfObjects and BucketSizeBytes. Both are in CloudWatch under the Daily Storage Metrics namespace. Useful for baseline awareness, completely useless for catching a request spike in anything close to real time because they only update once a day. If someone is hammering your bucket with GET requests you will not see it there until long after the damage is done.

The metrics that actually matter for catching runaway costs are AllRequests, GetRequests, and BytesDownloaded under the Request Metrics namespace. The catch is that Request Metrics are not enabled by default. You have to turn them on per bucket, and they come with their own CloudWatch costs, which is a fun little trap. But without them you are essentially flying blind on the request side.

For budget alerts, the AWS Budgets setup is straightforward but the default granularity is too coarse. Monthly budget alerts will tell you after the fact. If you set a daily spend threshold on S3 specifically and alert at something like 80% of that, you get enough lead time to actually investigate before the number compounds. The filter by service in Cost Explorer is your friend here, broken down by usage type so you can distinguish storage costs from request costs from data transfer.

The one that trips people up most is egress. BytesDownloaded in CloudWatch tells you what's leaving the bucket, but the billing impact depends heavily on where it's going. Same-region traffic to EC2 is free, CloudFront origins are free, everything else is not. The metric doesn't make that distinction so you have to cross-reference with Cost Explorer usage types to understand what's actually costing money versus what just looks alarming.

Practical setup that has held up: Request Metrics enabled on any public or high-traffic bucket, CloudWatch alarm on AllRequests with a threshold based on your normal traffic baseline (give it some room, maybe 3x normal), daily budget alert on S3 spend, and a Cost Explorer bookmark filtered to S3 by usage type that you actually check weekly rather than when something looks wrong.

The thing nobody tells you is that by the time a monthly budget alert fires you have probably already had a bad time. The monitoring has to be set up before the incident, not in response to one.

[ Removed by Reddit on account of violating the content policy. ]

Hi all! I built a workout tracking app called Fortis: Workout Log & Tracker and looking for people at NC State to try it out. Completely free on iOS and Android.

It has custom exercises, templates, RPE logging, estimated 1RM tracking, and you can share progress with friends. Think Strava but for lifting.

Still early on but a tool if you’re trying to stay consistent and have visibility into your own progress over time. Would love any feedback

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]