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.
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 (🤓).
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:
-
watchis used to describe and reason about what is being...watched. -
historyis 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 particularwatchitem going forward. These are unique per user. -
fully qualified URL: The full URL of the GET endpoint (including thehttp/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 before the end of the month. 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. Additionally, I'd love to answer any questions around it. I'm sure I've left some things out.
Top comments (10)
Great stuff! I am wondering if you can give me an example of how this works because for some reason I get confused on "software health trend monitoring solution aimed at legacy systems". Maybe I am overthinking it though.
Great work!!
I’ve developed a demo version of a file‑syncing software that connects two PCs through a secure, one‑time 6‑digit pairing code. Once paired, each PC designates a folder for synchronization. Any file dropped into the shared folder on one machine is automatically mirrored to the paired folder on the other.
The system uses peer‑to‑peer transfer when both devices are online for fast, direct syncing. If either device goes offline, files are temporarily stored in a database. Once the offline device reconnects, it automatically fetches the pending files from the database, ensuring no data is lost. Synchronization is fully bidirectional, keeping both folders up to date.
I would really love to hear your review on this.
Oh, that sounds cool! I've never built a file sharing anything like that before. I like the pairing code for a bit of security. What did you build that for?
Have you made a post on what you've built? I'm curious to hear more of the technical bits and the "whys" behind it all.
ebSync – Backstory & Vision
The idea for ebSync came from a simple but frustrating experience. One evening, I made some code changes on my PC before dinner. Later that night, I felt the urge to continue building, so I opened Claude and downloaded the file again—only to realize that the changes I had made earlier weren’t there. That’s when I thought: What if there were an app that automatically synced files between devices, regardless of whether the other device was online or not?
That spark led to ebSync.
How ebSync Works
You connect two devices by entering the same pair code on both.
Once connected, you assign a shared folder.
From that point forward, any file added to the shared folder on one device is automatically synced to the shared folder on the other device.
Initially, I built this using WebRTC peer-to-peer connections, with Supabase as a fallback for file transfers. I’m now exploring a shift toward direct TCP transfer architecture for greater efficiency and reliability.
Current Development
I’m iterating quickly to refine the product-market fit and uncover real-world use cases. One of the most exciting features I’m working on now is intelligent file organization:
Files are automatically tagged, summarized, and categorized into newly generated folders.
This means you no longer have to dig through endless chat threads or cluttered mobile storage to find a document.
Even if you don’t remember the exact filename, you can simply search for something like “Payment to John” and ebSync will surface the right PDF instantly.
The Goal
The vision is to make file syncing and retrieval effortless—not just keeping your devices in sync, but also making your files discoverable and meaningful. + to earn lot of money.
*The whole code is written by Claude
Oh, that's interesting. It sounds like a sort of "smart cloud". Where is your Supabase stored/running? I've heard of it, but never used it. How's the market-fit part going?
Absolutely! I know, it's a bit of a word salad. 😅
I'll break down what you quoted in hopefully better words.
My API sits in the cloud and essentially pings another GET endpoint every X minutes. The resulting response plus a couple extra metrics are recorded. This is the "software health monitoring" part. The "trend" part comes in after a bunch of responses have been recorded. Using any data visualization tech, user's can see the trends of the monitored system over time.
It's "aimed at legacy systems" or old systems because that's what I built it for and there's no integration or changes needed on the system being monitored. Alterations could help, but typically aren't required. This is assuming the software being monitored has at least a single GET endpoint that my system can reach from the cloud.
Does that make sense? Is there anything else I can word differently or clarify? I just assume there are things I say that don't make much sense and hope for questions. 😅
That would makes sense if you are doing a GET request. I think I am more confused on what data it contains when you mention "trends of the monitored system over time.". Just a high level understanding is where I am stuck on pretty much I believe. Though, explanation makes sense overall :)
Right. Of course I left that part out! 😅
The metrics that get recorded from every watch/ping response are
My dashboard plots the response times on the graph and shows the status code locations within the data (like the bottom watch in the screenshot/post image).
Does that make sense?
Yep! I actually have to take the time to think about it for couple of days and for some reason it just clicked (I read it closely and just had to marinate it a bit). Not sure why it was so hard. Thanks for the explanation!
Awesome, glad I could clarify things!
FWIW, I frequently step away and let things simmer/marinate in the back of my mind. 🙂