The Origin of Sermerce
Sermerce started because I wanted to start a home automation business.
I was not trying to build software at first. I was just trying to figure out how I would actually run the business.
I started thinking through everything that would have to happen.
A customer reaches out. I need to remember to call them back. I need to figure out what they want. I might need to schedule a visit. I need to write up an estimate. Maybe they approve it. Maybe they have questions. Maybe the job changes. Then I need to schedule the work, track what was done, collect payment, and keep the customer updated.
The more I thought about it, the more I realized the work itself was only part of the business.
The other part was staying organized enough to not let anything fall through the cracks.
So I started asking around and paying attention to how other service businesses handled all of this.
It was a mix.
Some smaller businesses were using paper, folders, notebooks, calendars, and memory.
Some had spreadsheets or documents.
Some had a quoting app.
Some had one system for scheduling, another for estimates, another for payments, and another for notes.
Some bigger businesses had expensive software, but even then it did not always seem like one clean system that handled the entire workflow from the customer’s first request to the final payment.
That is what stuck with me.
It was not that every business was disorganized. A lot of them had systems. Some had very good systems.
But it still felt like service businesses were often piecing things together.
And for smaller businesses, the better software could be too expensive to start with. That seemed backwards to me, because those are the businesses that need help staying organized the most.
I kept thinking, why is this so complicated?
The customer comes to the business through the website.
The business already needs a website.
So why is the actual service workflow usually somewhere else?
That was the part that bothered me.
If a customer wants work done on their house, business, property, event, or anything else, they usually start by finding the company’s website. That is where they meet the business. That is where they decide if the company looks trustworthy. That is where they look at the services.
So to me, the website should not just be a brochure.
It should be where the customer can actually start the process.
They should be able to see the services, request work, review what is being offered, approve the agreement, make payments, and know what is going on.
I wanted the customer to feel like they were at the table.
Not in some other company’s system.
Not sent off to some random portal that does not really feel like the business they hired.
Not wondering if anyone remembered to call them back.
I wanted the service business to own that experience on its own website.
That is one of the things I always liked about WooCommerce.
When a business sells products online with WooCommerce, the customer stays on that business’s website. They can look at products, create an account, place an order, see the status, and make a payment. The website becomes the place where the business and customer interact.
I kept thinking, that is basically what I want, but for services.
Not products.
Services.
I had already built WordPress websites before. I knew HTML, CSS, and a little PHP. I had used WooCommerce before too, but I had never really gone deep into how it worked.
From the outside, WooCommerce felt like a much bigger and more complex thing than regular WordPress because it handled orders, payments, customer accounts, emails, and all the serious parts of selling online.
So at first, I thought maybe I could just customize WooCommerce enough to make it work.
That seemed like the easier path.
I already knew services were different from products. I was not confused about that. I just thought maybe WooCommerce was flexible enough that I could bend it into the shape I needed without having to build everything from scratch.
And honestly, it did get me pretty far.
I started digging into WooCommerce and learning how much could be changed. I looked at statuses, payments, customer accounts, emails, templates, and how the customer moves through the process.
I kept asking myself, can I make this work for a service business?
For a while, the answer felt like maybe.
WooCommerce is extremely flexible. There are hooks and filters all over the place, and you can change a lot more than I expected.
But the deeper I went, the more I saw the problem.
WooCommerce was built around products.
That is not a bad thing. It is great at what it was made for.
But a product is usually pretty simple compared to a service. A customer buys it, pays for it, and receives it.
A service can be completely different.
There can be a request, a phone call, a consultation, an estimate, an agreement, a job location, scheduling, changes, approvals, deposits, invoices, final payments, and follow up.
The work can change before it starts.
It can change while it is happening.
The customer might need to approve something.
The business might need to go back and adjust the plan.
That is not the same thing as selling a product.
At some point, I realized that if I kept trying to force services into a product system, I was always going to be fighting the foundation underneath it.
It might work for a while.
It might even look good at first.
But long term, it would always feel like a workaround.
That was when I started thinking about building the thing directly around services.
That idea felt huge.
Honestly, it still does.
Building something like this is not a small project. There are a lot of moving parts. Customers, contacts, service locations, requests, agreements, jobs, invoices, payments, scheduling, history, and everything else that has to connect together.
But as I learned more, it started feeling less impossible.
I was learning WordPress more deeply.
I was learning WooCommerce more deeply.
I was learning PHP more seriously.
I was learning how plugins were built, how data should be organized, how business workflows fit together, and how quickly things can get messy if the foundation is wrong.
The more I learned, the more obvious the direction became.
Service businesses needed their own foundation.
That is what became Sermerce.
Sermerce is not being built because no other software exists.
There is plenty of software out there.
Some of it is very good.
Some businesses use expensive systems that help them stay organized, send estimates, collect payments, and manage customers. But even then, a lot of the time the business is working inside another company’s world.
The business has a website, but the real workflow happens somewhere else.
The customer starts with the business, but then they get pushed into a different system to pay, approve, or track what is happening.
That never felt right to me.
The website is where the customer meets the business.
So I kept coming back to the same question.
Why should the service workflow live somewhere else?
That question became the heart of Sermerce.
A service business should be able to run the customer side and the business side from its own website.
The customer should be able to understand what is happening.
The business should be able to keep track of the work.
The website should connect both sides.
And small businesses should be able to start with the core system without being forced into expensive monthly software just to look professional and stay organized.
I am not building Sermerce because every other system is bad.
I am building Sermerce because I think service businesses deserve another option.
An option where the business owns the website.
An option where the customer experience stays with the company they actually hired.
An option where services are treated as the main thing from the beginning.
Sermerce started because I wanted to run a home automation business better.
Then it became the system I kept expecting to find.