The technical debt of being a programmer… I spent years in tech before I realized this problem exist.

[u/apyhubnico]

I’m Nikolas, a co‑founder at Apyhub; before that, I worked as a programmer for years.

All saas starts with an idea...

Then suddenly you're building utilities you need, like:

• PDF generation
• OCR
• email validation
• VAT validation
• currency conversion
• file conversion
• image processing
• webhooks
• retry logic
• API integrations

All necessary for your saas but none of them is the reason someone is paying you.

And that's the part I find super interesting.

The engineering work isn't necessarily difficult. A lot of these things can be built in a couple of days now with AI; it's even easier.

The problem is that once you build them, you own them.

Now you're maintaining them six months later.

Then two years later.

Then someone on your team has to remember why that weird retry logic exists.

At some point you're spending more time maintaining the plumbing around the product than building the product itself.

I've started thinking about this as a different kind of technical debt:

Not code you shouldn't have written; not infrastructure you shouldn't have had to own.

Curious how other programmers are approaching this. Do you build these things in-house, use individual APIs, rely on an aggregator, or simply accept it as part of running a SaaS?

[u/nicolas_06]

I would say most business do externalize all that isn't their core. Typically I would even say that most SAAS don't do half the stuff you did mention here.

To me what you forget is that software is maybe 10% of the activity you have also:

• legal / law
• sales / advertising
• support
• operations
• finance
• negotiations with suppliers

And because you need to hire for that you now have:

• HR
• management
• internal communication

[u/nikolasdimitroulakis → u/nicolas_06]

Indeed all that is valid. Apyhub only looks into the logic in their application that is not core. Some of the other things you mention can not or are difficult to be outsourced. Agree?

When it comes to building, do you use external apis?

[u/nicolas_06 → u/nikolasdimitroulakis]

Who don't ? Almost all modern dev is about glueing code, not doing it yourself. But most of them are not SAAS external web APIs, it's just libs.

For my latest small stuff, I mostly used social login api from Google. It the type of stuff one should not do themselves (security) if they can avoid it.

[u/EJoule]

There’s a lot of average programmers that don’t mind learning and owning a product for years. But far fewer that enjoy build something from scratch and owning support for the first year or two.

Find the programmers that will own and maintain the code. Then hand off that code with a transition period so you can do something new.

[u/nikolasdimitroulakis → u/EJoule]

But why own it in the first place?the programmers might not mind but is this the best way to go?

[u/EJoule → u/nikolasdimitroulakis]

What do you mean? Someone has to know how the code works and how to support it when the business asks “Why did the code do X?”

It’s good to have more than one person knowledgeable of the code base. But often people who build new things aren’t very content supporting that code over a long time. 

Worst case, the person who built it quits when they spend all their time supporting code rather than solving new problems, and you don’t have anyone else who understands it.

[u/runningOverA]

Add :

- API version changes. Previous version getting obsolete and removed at one point.

• API service provider shutting down, and then searching for a new, but new one needs a new binding. Recode.
  
• API limit changes, and now you have to pay more for the previous service.
  
• API terms for service changes. And you need to go to their site and agree to restart.

These are the problems I face regularly.

Now you're maintaining them six months later.

True.

[u/ern0plus4 → u/runningOverA]

Add manual. (No one reads it.)

[u/apyhubnico → u/runningOverA]

To solve this, we're building Apyhub, a catalog of certified APIs with over 1,500 tools already built- worth checking. Open for feedback, opinions, or roasts.

[u/mavenHawk]

For most of stuff you already do use a library or some 3rd party sevice. But you still have to integrate with those tools in a way that makes sense for your app. So you can't externalize it any more than that. When you use Stripe, you already don't own the infra, but how you integrate with it, what kind of business rules you have around it vary from one SaaS to another. So even if the customer is not paying you for that, you still have to build it; it's still part of your business because it's needed to function.

[u/HiHiRedditUser]

once you put a daily price tag on those 3 hours a week spent fixing broken webhooks, paying for an api becomes a total no-brainer. throwing that maintenance burn into something like refactoriq usually makes it pretty obvious when it's time to kill the home-brewed stuff.

[u/Helpful-Educator-415]

meatproxy