After 6 months, I might have to shut down my API

Someone expressed interest in something I built and launched months back. I figured more people might be interested and maybe someone might be interested in using it - saving it.

I'm going to keep this pretty high-level and abstract here, but if anyone wants more details just drop a comment. I would love a chance to talk more about the technical aspects.

The thing

I won't bury the lead. I built a software health trend monitoring solution aimed at legacy systems. I called it BOCH (pronounced "botch"), which stands for Bill Of Clean Health. So users could get a bill of clean health on their legacy system (🤓). Having worked in several legacy systems, I noticed I always found myself wanting more trend-data on a system's health.

The beginning

I finished a contract in early October last year that had me under an IP ownership clause. After the contract I had this idea and got to work - launching soon after. I've been working on marketing it and looking for feedback since.

The weeds, let's get lost in them

BOCH is built in C# .Net 8 and PostgreSQL. It's hosted by a cloud provider and interfaces with RapidApi as the users' 'entrypoint'. My core stack is in C# .Net, so that made sense. The DB was pretty simple, too. I wanted a relational DB and wanted more experience with Postgres.

I built BOCH in a way that didn't require any integration steps in the code. It only required a GET endpoint that could be hit from BOCH to start. For some reason it took me a few weeks of marketing to realize that things were set up for such a simple/easy onboarding. 😅

There are two important atomic terms for BOCH:

• watch is used to describe and reason about what is being...watched.
• history is the record of a single execution/hit of a watched URL.

watch
Setting up a single watch is all that's needed to get started in observing a URL. Sending a single request to the AddWatch endpoint only requires this data to be filled in:

• watch name: a user friendly name to refer to the particular watch item going forward. These are unique per user.
• fully qualified URL: The full URL of the GET endpoint (including the http/s://) to be observed.
• interval in minutes: How frequently should the endpoint be observed. Limited by the customer-tier of a user. The system is set up for observing at most once per minute.
• (optionally) custom headers: Custom headers are offered for anyone wanting them to be sent with the REST request.

history
After BOCH runs a bit, the user can see the resulting history data. Each time BOCH reaches out and 'ping's a watched URL, the datapoints below are recorded and available from a single request. All history objects are stored and made available for 7 days.

• datetime: The date and time the request/ping was made.
• status code: Resulting status code returned from the watched URL.
• response time ms: How long the total watch-ping time took.
• peek response content: 64 characters of the response body.

Since I built and launched it while entering the job market, I took the ubiquitous request for AI experience to heart. I vibe coded a dashboard as a companion to my main offering - the API. I also made it opensource (MIT license) so that anyone could use it as a useful starting point for their own needs. The image I choose for this post is one of the screenshots of the dashboard.

I also made sure to centralize several aspects in a config file. So many aspects were configurable with this. The 'rounding' of the graph-data (P95, P99, P90, etc.), forced green-yellow-red for specific response codes, and even which filter duration to use/show. My favorite is the mechanism where clicking on a datapoint copies the atomic data behind it to the user's clipboard.

This dashboard really opened up what users can do with BOCH. Something about being able to view, filter, configure, and zoom in on the data just made things click.

The end

I said sometime shortly after launching that I'd keep it going as long as I can financially manage to.

That time appears to be up. Unless I get at least one paying user, I'm planning on shutting the service down towards the end of next week. It just costs too much with no income on my part to justify it now.

Lessons

I don't know that I'd be able to fully list all of the things I've learned along this journey. I was really looking forward to seeing what off-the-walls stuff this might get used for. I built it for better health metrics in legacy systems, but I know how these things go.

This was my first product launch after years of "working on side projects". It's an amazing feeling to actually launch something.

If anyone is interest in some sort of postmortem or retrospective, I can make a post around that.