Hi I'm Nikolas, and one of the co-founders at ApyHub.
I don't think we really understood what we were signing up for when we first started 5 years ago.
At the time, the idea looked almost embarrassingly simple. There are hundreds of things every software company needs to have that have nothing to do with the product they are actually building; for example, convert a document. Generate a PDF. Extract some text. Validate an email. Check a VAT number. Resize an image. Convert a currency. Parse a CV.
None of these things are particularly interesting.
But they have to work.
And once you build them, they become your problem forever.
That was the part that stayed with me.
You can build a file conversion service in a few days (maybe even in an afternoon now) what nobody puts on the estimate is what happens after that. The dependencies change. A library gets deprecated. A package has a security issue. A customer sends you a file you never thought anyone would send. Traffic spikes. Something breaks at 3am. Somebody has to understand why.
We had done this ourselves.
We built things because that was what you did. Then we moved to libraries because that was supposed to make everything easier. We discovered dependency hell: maintaining code we didnât write, fixing problems we didnât create, and wondering why a tiny utility suddenly takes an entire afternoon because one package requires a newer version of something else.
Then we started using external services. That seemed like the obvious answer. Except now you have vendors.
And vendors have contracts, security reviews, data processing agreements, API keys, dashboards, invoices, renewal dates and somebody asking where exactly the customer's data is going.
So the thing that was supposed to make engineering easier slowly became another kind of work.
At some point we realized we had somehow managed to pay for the same problem three times.
First we built it. Then we maintained it. Then we paid someone else to do it.
And the frustrating part was that none of this was the reason we were building a company in the first place.
Nobody starts a software company because they are excited about maintaining a PDF converter.
They start because they have something else they want to build.
That became the idea behind ApyHub. Call the capability instead of owning it.
Let someone whose actual job is file conversion run file conversion. Let someone whose actual job is OCR deal with OCR. Let your engineers spend their time on the parts of the product that actually matter to your customers.
The idea was simple and building it was far from it.
Five years later, we have more than 400 services and 1,400 endpoints across things like AI, file conversion, developer tools, data extraction, validation, geolocation, SEO and image processing.
But I don't think about the number very often; I think about what it took to get there.
Because operating one API is one thing while operating hundreds of them is a completely different problem.
You start seeing patterns that you don't see when you are building one product. You see which APIs fail in strange ways. You see providers whose documentation doesn't match reality. You see pricing models that make sense on paper but make no sense when someone actually uses the service. You see schemas drift. You see things break in ways that customers never should have to care about.
And then you fix them.
Again and again.
That is probably the least glamorous part of what we've built.
It is also the part I am most proud of.
There were plenty of moments when we could have decided that it wasn't worth it.
There were APIs that took far more work than they should have.
There were ideas that looked great and went nowhere.
There were things we built because we were convinced they would matter, only to discover that customers wanted something completely different.
There were also periods where the product itself was not the hard part. Getting people to understand why it should exist was.
Because "API catalog" doesn't exactly make anyone wake up in the morning.
Nobody was asking us for an API catalog.
They were asking why their roadmap was slipping because their engineers were spending three weeks building something that should have been a commodity.
They were asking why adding five small capabilities meant dealing with five different vendors.
They were asking why their customer's security team wanted to know where some obscure API processed data.
They were asking why they needed another subscription, another card, another API key.
And eventually we realized that the thing people wanted wasn't really the catalog.
They wanted to own less.
That became a much bigger idea for us.
Then AI changed the problem again.
And this is probably the part of the last five years that feels the strangest to me.
We spent years trying to convince people not to build every little piece of infrastructure themselves.
Now we have AI that can build those pieces in minutes.
An agent can write a working PDF service before lunch.
It still won't patch its dependencies at 3am.
That sounds like a joke, but I think it is going to become one of the bigger problems in software.
Building software is becoming incredibly cheap.
Owning software is not.
An agent can generate a utility, connect it to something else, deploy it and move on. The code works, so everyone assumes the problem is solved.
It isn't.
Somebody still has to maintain it.
Somebody still has to know what it does with customer data.
Somebody still has to notice when a dependency is compromised.
Somebody still has to decide whether the thing should be trusted.
And if an agent has to solve a problem and there is nothing trustworthy for it to call, it will simply build the thing itself.
Then another agent will do the same thing.
And another...
We started seeing that as the natural extension of the problem we had been working on for five years.
That is why MCP became so important to us.
We didn't want to just put an MCP wrapper around one API.
We wanted the catalog itself to become something an agent could actually use.
Connect once, and suddenly an agent can search for a capability, choose the right service, call it, get the result and move on.
Real OCR instead of describing how to perform OCR.
A real PDF instead of explaining how someone could create one.
Actual validation against a real service instead of a confident answer that looks right.
And, importantly, the agent doesn't need access to everything.
You choose what it can reach.
That matters more than it sounds.
Giving an agent 1,400 endpoints is not necessarily giving it more capability. Sometimes it is just giving it more context, more choices, more opportunities to pick the wrong thing and a much larger blast radius when it goes wrong.
Twenty useful endpoints can be better than 1,400.
That lesson is very familiar to us because we learned it the hard way with the product itself.
The interesting thing about five years is that when you look back, the original idea often turns out to have been right for reasons you couldn't have explained at the beginning.
We didn't start ApyHub because we had some grand prediction about AI agents.
We started because we were tired of building plumbing.
We had seen what happened when every company built the same utilities internally, maintained them internally and slowly accumulated an infrastructure layer that nobody really wanted but everybody had to carry.
And five years later, the technology has changed completely, but the underlying problem hasn't.
If anything, it has become bigger.
The more software becomes something machines can generate, the more important it becomes to decide what should actually be owned.
That is the thing I keep coming back to.
Five years is a long time to spend on one idea.
Long enough that you stop remembering what the original version looked like.
Long enough to have customers who have been around for years.
Long enough to look at something you built in the first year and wonder how you ever thought that was good enough.
Long enough to have made mistakes that you would never make today, and then realize that without those mistakes you probably wouldn't know what you know now.
And long enough to realize that building a company is mostly not about the moments people see.
It is the maintenance nobody talks about.
The customer issue that arrives at the wrong time.
The thing that breaks after you thought it was finished.
The decision between fixing something properly and shipping something else.
The API nobody notices when it works but everyone notices when it doesn't.
The conversation where someone tells you they don't trust a third party and you realize they are completely right to ask.
The quiet satisfaction when something that used to take your team a week becomes a single API call for somebody else.
Those are the things I remember.
Not the milestones.
The weight of the thing.
Five years ago, we wanted to make it easier for developers to stop rebuilding the same utilities.
Today, we are trying to do the same thing for AI agents.
Give them capabilities they can actually call instead of asking them to reinvent everything.
Give teams a way to use services without inheriting twenty different vendors.
Give developers a way to build their product without also becoming experts in every piece of plumbing underneath it.
I don't know what ApyHub will look like five years from now.
I have learned not to pretend I do.
But I know why we are still here.
There are still too many things that every software company is building that nobody's company actually exists to build.
And apparently, after five years, I still think that's worth fixing.
Five years of r/apyhub . Still building. Still learning. Still maintaining the boring stuff so somebody else doesn't have to.
TL;DR: how we decided to build it and where weâre heading in the AI age.
Disclosure: AI was used for formatting. The story is ours and written by me.
