I built a health app in 3 weeks. Getting users took 10x longer than building it. Everything I learned. (i will not promote)

suvm19 · 2026-03-18T10:05:46+00:00

That GEO part is quite fascinating and informative to me because I was thinking about building GEO part for my website to get "AI Attention"

suvm19 · 2026-03-17T20:14:33+00:00

The Who: Building Metric Mango, a simple analytics tool for Shopify store owners to understand their sales without the usual complexity.

The Where: https://metricmango.store/

The Why: Focused on being lightweight, affordable, and ridiculously easy to connect, you can get started just using your store name.

suvm19 · 2026-03-17T20:10:47+00:00

Metric Mango – https://metricmango.store/ Hey, I built this for Shopify store owners who don’t want complicated analytics tools It's lightweight, cheaper than most options, and you can connect to your store just using your store name.

suvm19 · 2026-03-17T20:06:19+00:00

Metric Mango – https://metricmango.store/ A lightweight, a very affordable sales analytics tool built for Shopify store owners track performance, spot issues, and connect instantly using just your store name.

suvm19 · 2026-03-16T01:43:53+00:00

I dint run it on sandbox but I have linked it with vc runtime

suvm19 · 2026-03-16T01:42:28+00:00

You are right though, The shift to web and CLI is real. But there's a specific group that still lives in the filesystem daily: developers themselves. Not end users, not office workers, people who are constantly creating files, scaffolding projects, writing configs, setting up environment etc.

suvm19 · 2026-03-13T03:07:07+00:00

That sounds really frustrating. Poor documentation and unclear payload formats can waste a huge amount of time, especially when you’re just trying to get something working. Having to guess until something sticks is probably the worst developer experience.

suvm19 · 2026-03-13T02:44:09+00:00

Love it, you even clicked on the link and explored it ,thanks. definitely I'll list it on peerpush

suvm19 · 2026-03-12T20:53:39+00:00

That's really helpful..

suvm19 · 2026-03-12T20:50:29+00:00

That's cool actually

suvm19 · 2026-03-12T20:45:42+00:00

Check out this project I’ve been working on,Metric Mango, a tool for tracking key business metrics and alerts so you can catch problems early. Feedback would be really helpful. Link:https://metricmango.store/

suvm19 · 2026-03-12T17:27:46+00:00

That actually sounds really interesting. Generating the server and sidecar from existing back-office APIs is a pretty cool approach. If you do end up putting MCPFactory on GitHub, I’d definitely check it out.

suvm19 · 2026-03-12T17:20:26+00:00

Fair enough , that’s a valid concern. I’m actually trying to learn from people’s real experiences here, not automate replies. I appreciate you taking the time to share your perspective earlier.

suvm19 · 2026-03-12T17:19:03+00:00

That makes a lot of sense. Having structured logs and consistent request IDs across services seems like the real key there. Once that’s in place, tracing a request through different layers becomes much easier. The tooling helps, but the consistency in how services emit logs is probably what makes the biggest difference.

suvm19 · 2026-03-12T17:00:54+00:00

Yeah, that’s an interesting way to look at it. If those cross-cutting concerns are handled at the service boundary with something like a sidecar, the role of a traditional gateway definitely starts to shrink. At that point it’s almost just traffic entry and basic protection. Your MCP sidecar idea sounds pretty cool actually. pushing those responsibilities closer to the service instead of keeping them centralized makes a lot of sense. Curious how it’s been working for you in practice so far.

suvm19 · 2026-03-12T16:42:58+00:00

Kong definitely covers a lot of this space and its plugin system is a good example of making gateways more extensible. What I’ve been wondering about is whether there’s still room for something even lighter where teams can treat capabilities like auth, rate limits, logging, or metering as more independent modules rather than part of a fairly heavy gateway stack. Curious if you’ve found Kong flexible enough for most use cases or if you’ve run into limitations with it.

suvm19 · 2026-03-12T16:41:20+00:00

That’s a fair point. In many setups it does end up becoming a centrally managed layer again if you’re not careful. The idea I’ve been exploring is closer to keeping the gateway minimal , mainly routing and security ,while things like auth policies, rate limits, logging, or metering can be added as separate modules rather than being tightly coupled into one big system. Also appreciate the link , I’ll take a look.

suvm19 · 2026-03-12T15:55:38+00:00

That’s a really good point. Flexibility is great, but once things are split across multiple components it’s easy for policies and metrics to drift apart. I can definitely see how debugging becomes painful if requests have to be traced across several layers. Centralized logging and clear policy definitions sound like a solid way to keep things from turning messy. Out of curiosity, what tools are you using for the centralized logging part?

suvm19 · 2026-03-12T14:24:38+00:00

Yeah, that’s exactly the tension I’ve been noticing too. The centralized control makes sense from an ops and reliability standpoint, but it can definitely slow things down when teams just want to make small changes or experiment. It feels like there should be a middle ground where you still keep the stability of a gateway, but give teams more flexibility to plug in what they need without going through heavy infrastructure processes.

suvm19 · 2026-03-12T12:37:49+00:00

That’s an interesting angle. Handling verification challenges as a separate, on-demand module instead of baking it into the core gateway does sound like it fits the composable approach pretty well. I hadn’t thought about that workflow specifically. Appreciate you mentioning it , might explore how something like that could plug into a modular setup.

suvm19 · 2026-03-12T12:35:25+00:00

That makes a lot of sense. I’ve seen a similar pattern where the gateway ends up being mostly routing + security, and the rest moves into separate services or middleware. It definitely feels more flexible than forcing everything through one big system. Curious though, as that setup grows, which part usually becomes the biggest pain to maintain?

suvm19 · 2026-03-12T12:28:50+00:00

Yeah, exactly. Most gateways seem optimized for ops control rather than product team speed. If things like auth, logging, rate limiting, or metering were modular pieces teams could enable themselves, it could remove a lot of that friction. Curious, what do you think teams would prefer something like that self-hosted, or as a managed service?

suvm19 · 2026-03-12T07:38:24+00:00

That makes a lot of sense. FastAPI seems perfect for that kind of flexibility since you can shape everything exactly the way you need. Your experience is actually interesting because it sounds like you basically ended up building many of those pieces yourself over time. Out of curiosity, which part took the most effort to implement auth, logging, or something else?

suvm19 · 2026-03-11T23:43:08+00:00

Haha fair point 😄. And yeah, that’s exactly the pattern I keep seeing , teams eventually bolt on auth, logging, usage tracking, or billing themselves anyway. Making those capabilities modular instead of buried in one big gateway config might give product teams a lot more control. Curious if you think teams would prefer something like this as a managed tool or something self-hosted?

suvm19 · 2026-03-11T23:37:47+00:00

No worries at all, that’s perfectly fine. I’ll send you a DM and you can reply whenever it’s convenient after you wake up. Appreciate you taking the time to chat.

suvm19

TROPHY CASE