Hacker Newsnew | past | comments | ask | show | jobs | submit | debarshri's commentslogin

Agreed

It funny how this is the first problem statement all backend engineers think of.

I think with some rate limiting, it can scale. But it might be a security issue as ideally you don't want client to be aware of kubernetes also, it would be difficult to scope the access.

Yes, worked for speed camera company. It does have a cellular modem connecting over VPN or some tunneling with cloud infrastructure.

Sharing passphrase becomes even bigger risk as now your surface area is larger as comprise will lead to many credentials bei g leaked.


Of course. This is absolutely never used for sharing. That’s why it’s called out as a drawback. When I need a shared credential, I’m forced to use a completely different mechanism. But this is pretty rare with good practices (which discourage shared credentials).


I think secrets ending up in the log is an issue but who should have access to view logs of what log should also be an important that is often ignored. This is also scope down the surface area of leakage.


A user's password is something I shouldn't see in a log, even if I'm in control of what gets logged and frequently access them to do my job.

Even if I trust me.

Audits happen. I assume other people will eventually see this bad practice.


Audits and bad practice are second-order things.

My argument is that generally everyone has access to all the logs. If you restrict the access and add guardrails around it, you can minimize the surface area and also ways it can be leaked out.

If you take a defensive approach towards, you have to assume that some secret is getting logged somewhere. The goal then becomes a way to reduce the surface area or blast radius of this possible leakage.


Limiting access helps, but if you are storing the logs on a 3rd party (e.g. DataDog, CloudWatch), you will still need to assume it can leak through that 3rd party and start rotating.


You can always negotiate the price


In other words: you can always make the buying process more complex and expensive.

For some products that might be worth it. For other not.

But whatever the outcome: you still got to track license compliance afterwards and renew licenses. (Which also works better when tracking internal usage as you know your need)


At peak amplitude's market cap was 10B


Amplitude is on track to be delisted lol


I think you are under estimating the nuances you have in non faang infrastructure. Also, based on my previous experience you will meet with developer resistance (may be AI can help you beat that). By being broad you also competing with purpose built solution like finops, devsecops etc. Who also seems to have agents now.

It is workflow automation in the end of the day. I would rather pick SOAR or AI-SOC where automation like this is very common. For eg blinkops or torq.


That's fair. For what it's worth, our agents are being used by small startups in the YC batch and they have been helpful for them.

We have not spent as much time working in the security space, and I do think that purpose-built solutions are better if you only care about security. We are purposefully trying to stay broad, which might mean that our agents lack depth in specific verticals.


I wouldnt index on these startups. People who would pay big bucks are in enterprise. Thats largely your market.


Totally agree, enterprise is where the most $ is to be made, but from what we've found they care a lot about doing one specific thing very well. This has been something we've been thinking about. For now we've enjoyed working with startups as they have very interesting challenges that only appear at smaller scale.


I'm very excited about your company. Would be fun to chat about GTM with you guys.


Would love to! I think I just found and added you on LinkedIn


Building Infrastructure company is challenging in 2025. Previously, you would prioritize traction among developers over focusing on revenue.

But that does not work in 2025. You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.


> Previously, you would prioritize traction among developers over focusing on revenue.

A.k.a. using open source as a marketing tactic to lure in customers, only to do a rug pull once the business gains enough momentum.

> But that does not work in 2025.

Good. It is an insidious practice. There are very few projects that actually do this properly without turning their backs on the users who made their products popular in the first place.

> You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.

The strategy of delivering valuable products that benefit users without exploiting them has always existed. The thing is that many companies choose the greedy and user hostile path, instead of running a sustainable business that delivers value to humanity and not just to shareholders, which is much more difficult. So I have no sympathy towards these companies.


The problem I think is that all the easy infrastructure problems have been solved and the market is crowded with those solutions. Solving the hard problems is probably where you could have a viable business but I don't really see that many companies trying to solve those:

* Making mono-repos work for large companies.

* Mixed language builds are still a ci/cd unsolved problems for most companies.

* Testing strategies for Iac deployments.

And more that I won't bother to list here.


This would make a great blog post: high hanging fruit of digital infrastructure


So, you're saying in 2025 businesses are expected to actually make money? What a novel concept. Will the wonders ever cease? I mean, you could expect that thing where you borrow incessantly to "gain traction" and "produce growth" but never produce any returns on it to run for a bit, especially in a new field where becoming #1 is at premium. But it has to stop somewhere. So it looks like somewhere is here.


The outcomes of this behavior will be devastating and the problems will last for generations.


Most of these companies and technologies won't last that long.


Software generations are measured in months, maybe that's what they meant?


Why?


Asking the billion dollar questions I see.


I have an infrastructure company and I'm focused 100% on developers. It definitely isn't easy, but I see it as the best path for the business.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: