skroob.com

Thought I forgot, didn't you? 🙂 I've been taking it easy on the writing for the holidays, but still plugging away on the app.

Made some changes for the sake of seeing progress. I put the Vapor version aside for now, and fired up a simple PocketBase version of the backend that will work for proving the concept. That allowed me to start work on the widget and the dashboard, which I'm doing at the same time. I'm building them both into the dashboard app because, well, how would one of my customers request support on the service? Through the service itself, of course! So I'll pull the widget out as a Swift package when it's implemented.

Related: I've always been looking for a simple phrase I can use to describe what I do. “Oh, Mike? He's the ___ guy.” The blank has been filled in with “Apple”, “iPhone”, “Mobile Developer”, various unflattering remarks... But I think I've got something I really like. What do I do? I help small businesses communicate with their customers. It applies to Sysop, it applies to my work at Breezy, and it applies to lots of other things I've done in the past and would like to do in the future. So that's what I'm going with, until and unless something better comes along.

So I took the day off yesterday, and some of this morning to do some Christmas shopping, but I'm back on it now. Small thought in the intervening time. I'm worried about the eventual size and performance of the Message table. It'll be working real hard, real fast, if this thing sees almost any use at all. With a Postgres database behind it, I'll probably get several millions of entries before it becomes a problem I can't just throw more hardware at, but something to be aware of for the future.

Moving on. Last place I left this was being able to create messages between users via an api call. I think the next step is to start laying out the process of creating those users.

I need to keep reminding myself. This is a prototype, a proof of concept. It doesn't need to be robust. It doesn't need to even be correct, all the way anyway. If the app works, if people like the idea, I can refine it. Right now, I need to be in Get It Done mode. I might need to write that a few more times before this is over, because I'm optimizing this database in my head right now and I do not need to be doing that.

Okay. Update the User model to contain a one-to-many reference to any Messages it has and rename it to EndUser to avoid confusion. Update Message and simplify. Company and EndUser, and a bool flag to decide if it was sent by the user or not. Company model is just an id and a name for now. Update the migrations and rebuild everything.

I'll need a separate admin tool for creating Company entries. No big deal to do that manually for now. In the meantime, I'll fill out the CRUD routes for EndUser and Message.

Last night I got the basics set up for developing this backend. A Linode instance, Docker, Vapor and all that set up. Today I'm focusing on getting the most basic functionality levels in place for the API. I'm typing this out as I write the code, so this is going to be very stream of consciousness as I sort all this out.

First, I need a model for a single message. I set up Vapor with Fluent support and a SQLite database, so it's straightforward. It will need to transition into a more robust database before it goes live, but Fluent should be able to just handle that. The Message needs a timestamp, content (a string for now, will need to be expanded later), a creator and a destination. Creator and destination will be an ID that references either a customer or an end user. I'm just going to call them “Users” I guess. They're all using the app anyway. Make it simple for now, just an ID. Flesh that out more later.

Okay, create the migrations for both objects. Github Copilot is surprisingly helpful in all this, I didn't think it would do well with Vapor but I'm impressed.

Built a route for creating a user and a message, threw everything into Postman, debugged and we have a message! Vapor is cool 😊.

Next up, I need to start laying out exactly what this project is going to do and how it's going to work.

There's two main pieces to this project. The dashboard app and the widget. The dashboard app is what customers will use to provide support, and the widget will integrate into the customer's app and be used by end users to request and receive support.

So here's a decision I just made. For the simple reason that I have limited time to get something going, I'm going to focus this first version on iOS (and Mac) entirely. Meaning, the widget will be an importable Swift package, and the dashboard will be a hybrid iOS/iPadOS/Mac app. Eventually, the next step will have to be a JavaScript widget and a web dashboard, but I'm just not gonna have the time to get a prototype out if I shoot for that first.

So, starting with the dashboard. Basic needs are a way to see a list of support requests, which links into a screen that allows that two way communication. That communication would be text, images, links, and documents at minimum. Also a way to mark a request as completed.

As for the widget. It would need to be a communication screen that can send and receive the same types of content, and a way to complete the request from the end user side. It should provide an SDK call and a standard button widget for the customer to use when integrating.

Finally, there's a third piece I haven't mentioned yet. The backend that ties all this together, facilitates and stores all this communication. Am I insane to do the API in Vapor? Definitely, but I think I'm gonna anyway. All of this should be replaceable or upgradable later on down the line if/when I outgrow what Vapor can do.

Okay. Time to start writing some code. I'm going to start with the backend, because I think it'll take the longest. I'll get started up today with the basics and try to knock out as much as I can tomorrow.

Okay, step one here is going to be laying out the concept of what this product is going to do and be. At least initially. It's going to be pretty stream of consciousness, so maybe not the best writing I've ever done, but it's mostly to get the ideas out and written down for later reference.

---

So. In a general sense, Sysop is a platform for micro-businesses to communicate with their end users. I'm going to use the term “customer” to refer to Sysop customers/users, and “end users” to refer to the micro-business's customers.

What does that really entail? Well there's two ways to go. The first is a SaaS-targeted approach, which would put me in a field with companies like Intercom. Customers would likely be individual or very small teams of developers, in a launched or about-to-launch startup company, and would consist of a suite of apps on their end (mobile/desktop/web, probably) that would allow communication with end users, and a widget (likely web at first, then mobile/desktop SDKs) that would integrate with their product and allow the users to reach out. Differentiating factors would be a focus on individualized support, rather than expecting a team of CS people, and a focus on providing support from mobile. This was my initial idea for this project.

A second approach was suggested to me: targeting professional services providers. Lawyers, CPAs, designers, consultants, that kind of thing. It would again consist of an app, probably heavier mobile but web/desktop would still be important here, but there wouldn't really be a good way to get end users onboard. Maybe an end user mobile app and a slim web interface. Competition here is a bit trickier, because while there's plenty of CRM and professional service management platforms out there that can do all kinds of things, the main competition is plain old free email and phone, which I expect is how most of these companies are handling their customer support right now anyway.

The professional services approach has a few positives over the SaaS approach.. It targets companies that are likely already succeeding in general and would have more financial freedom to pay for a service like this. It naturally can segment itself into each field, allowing more specific niche targeting at the edges while maintaining the core product. It has the potential to grow organically into an overall CRM system. The SaaS approach is missing a lot of that; niche segments are possible but “solopreneur” is already pretty nichey anyway. But the big one is that I'm just not sure professional services providers even really need something like this. They already communicate through email and phone, and maintain data through CRMs or niche management platforms or pen and paper, so what does something like this even bring to the table?

And that's why I did this post. To get all this out and make sure I go in the right direction. Maybe the professional services approach would work for a pivot or an additional product down the line, but for now the SaaS approach is the one I want.

Great. What's next?

Through a series of events that mostly consists of me forgetting to spend my vacation days, I'm off work for the rest of the year. Three weeks is probably enough time to at least start a project, right? Get a rough draft of it together and see if people are interested?

---

Here's what I'm thinking. Communication with your customers is vital when something goes wrong on their end and they need to reach out. That's fine for companies with dedicated Customer Support teams, ready to help whenever a question comes in. But what about for businesses without that? What about solopreneurs, micro-businesses, startups with just a programmer or two?

Back in the 80s, there were these things called Bulletin Board Systems. You would call into them with a modem, and special BBS software on the other end would provide services, in the form of games, message boards, mail, and so on. But the thing is, you were basically just phoning up some other person's computer. And sometimes, that person was sitting there in front of the computer, and you could do something that was really uncommon for that time frame.

You could chat with them, live.

The person running the BBS was called a sysop, short for System Operator. They could set a flag in their BBS software that would let the dialed in user know, usually in the main menu somewhere, that the “Sysop was available for chat”. And if you selected it, it would let them know that you wanted to chat, and open a two way communications screen and you could text chat about whatever, in real time.

The idea of sysop chat hit me the other day as I was researching potential projects for my time off. For small apps and services, chances are decent if you need support, you're getting it from the person running everything, just like the sysop was back in the BBS days. So, why not build a customer support platform specifically for those kinds of projects? And I'm (at least for now, maybe forever) calling it Sysop.

I'd like to keep this blog going as a diary of how this project goes down. Maybe it'll be interesting, maybe it'll just help me keep my thoughts organized. If you're reading this, I hope there's like 20 more posts underneath it talking about how I'm taking this thing from an idea and a nostalgic memory of the Good Ol' Days of 2400 baud, and turning into a real product that helps people.