c0nrad

Second/current one, dmarcdefender.io (2025), took maybe 6 months till I had my first customer, but now it's growing much slower. There's a lot more competition and still trying to figure out where I fit in / how to market it among all the competition. I was originally positioned as a security focused product, but now pivoting to more of a marketing/deliverability product. But to be honest not really sure where it's going, but still fighting the fight.

https://youtube.com/@SloppyJoePirates

Ha, I haven't profiled it yet. I'm not too sure. But, I think a decent amount. If a slack team with 10000+ physicists signs up, I may need to talk to them offline.

I do plan on doing some stress testing in the future for fun, I'll try to remember to reply here.

> partner frontend

Yep, to repeat what steve_adams_86 said, she did the frontend completely. Usually I'm forced to do the frontend, it was very nice having someone else just do the whole thing without me.

True, it probably would have made sense to stay completely within AWS. If I didn't know MongoDB very well, I would have used DynamoDB.

But I know MongoDB well, and MongoDB Atlas (the hosted platform) also has a free tier, and it's hosted in ec2, and you can setup VPC peering (so network speed _should_ be comparable to dynamo, but not sure).

Also, Atlas (MongoDB's Cloud Platform) has a really nice "charts" product (sort of like a built in web based tableau) which I use for my internal dashboards (it takes <5 minutes to setup, for stuff like "how many customers do I have", "at what stage in the pipeline are they", "how many renders does each customer average", etc), and they have a nice web based "query explorer", which I randomly use when debugging something, when I don't feel like connecting with terminal.

But yeah, if I wasn't already biased, I would have used DynamoDB.

Thankfully lots of tools do most of the heavy lifting. I use k8s, GKE does most of the work for me. It's very nice to have autoscaling for traffic spikes. Same with database (MongoDB Altas), dead simple autoscaling. I would never run my own k8s nor database.

I wrote more details about some of the Ops stuff I do here in a previous similar question: https://news.ycombinator.com/item?id=26204402

Coincidentally I also wrote some architecture notes about a new product last night: https://blog.c0nrad.io/posts/slack-latex/

I think everyone's milage will very, but as general principles, staging is nice, reading docs saves time overall, tests help you sleep at night and make it easier to make changes 6 months in the future, simple health checks (or anything on a critical path) help you catch the real issues that need immediate attention.

Good luck!

If I remember correctly you can specify a bunch of regions for the health checks to originate from. It was super simple to setup (point and click) and it's nice that it's decoupled from the rest of my infrastructure. When there's a failure I get a notification.

It's easier said than done, but if you can prevent issues in the first place, things will be much more enjoyable.

Some things that worked well for me:

  * GKE on GCP is pretty smooth. When there's a spike in traffic everything autoscales up, so I don't have to do anything. Nice observability, things just work. Just make sure to set container cpu/mem limits.
  * Along that same note, I use MongoDB Atlas which also autoscales very nicely. It autoscales both up and down very well, saving both money, and making my infra resilient
  * GCP has a lot of monitoring/alerting/dashboards that I take advantage of. Health checks around the world, easy integration of logs/metrics. I find structured logging (json), makes setting up alerts pretty easy
  * Good consolidated logging for when there is an issue you know exactly what went wrong
  * GCP also support application tracing which can make timing issues easy to debug (although it requires a bit of work to setup) (for example if you are missing an index on some db)
  * Automatic deployments (thanks to k8s), there's no checklist for doing a deploy, I just run a single make command. I can't screw that up
  * A staging environment that's a match of production. Plenty of times I've crashed staging, it's worth every penny. It also makes life much less stressful
  * Lots of tests. The tests aren't important for when I'm writing the code, but for months later when I make changes and want to know I didn't mess something else up. I find a good test suite can really help you sleep at night, specially if the test suite covers the critical paths
  * An easy way for users to contact you if there is an issue. No one is perfect, but being able to respond quickly is usually forgiven.

Hope that helps!

https://blog.c0nrad.io/posts/thermoshat/

I helped setup CSP at a company back when I was an intern (2013). I learned that CSP can be an unpleasant experience.

A year ago I decided I wanted to do something new with my life so I quit my job and Csper was born. Hopefully it makes CSP easier for other people.

It's not super profitable, but it almost pays my rent, no complaints.

  Location: Michigan, USA
  Remote: Yes
  Willing to relocate: Yes
  Current Position: CEO/Founder of profitable startup
  Previous: Yahoo! MongoDB
  Resume/CV: https://c0nrad.io, https://github.com/c0nrad
  Email: [email protected]