I have been building web applications in PHP since 2007, and in that time I have noticed something about the projects that turn out well. They almost never start with a feature list. They start with a sentence like "this takes too long."
That sentence is where my favorite kind of work begins. Somebody walks me through a business process that eats hours every week, usually held together by a spreadsheet and a lot of patience, and I start sketching the software that fixes it. The unoptimized business process has been my favorite problem for my whole career, and I want to explain why I think it is the right starting point for almost any software project.
Feature lists describe software. Processes describe problems.
When a business owner sits down to plan a project, the natural instinct is to write down features. A dashboard. User accounts. Reports. Email notifications. It feels productive, and it looks like progress.
The trouble is that a feature list describes software that does not exist yet, written by someone who has not built it. It skips the most valuable information the owner has: what actually happens in the business today, step by step, and where it hurts. The features are guesses about a solution. The process is the truth about the problem.
When I hear the process first, the right features tend to fall out on their own. When I get the feature list first, I usually end up asking questions until we arrive back at the process anyway. Starting there just saves a step.
What that looked like with Knowledge ERP
Knowledge ERP, the inventory management product I have been building since 2016 at Pelton Solutions, came out of exactly this kind of thinking. Inventory is full of unoptimized processes. Teams track stock by hand or in spreadsheets that were never meant to carry that weight, and a well-built web application can take that work over.
The product's core is detailed item tracking that adapts to how an organization actually handles its stock, instead of forcing the organization to adapt to the software. And the feature I get asked about most, check in and check out, exists because of a specific process pain. Organizations that rent or loan equipment need to know what is out, who has it, and when it came back. Nobody ever asked me for a "check-out module" by name. They described gear leaving the building and not coming home, and the feature followed from that.
Because I run the sales demos and support myself, I hear these process descriptions directly from the people living with them, and that feedback goes straight back into development. It keeps the product honest.
What it looked like at Successories
The same pattern shows up in my work at Successories, where I have been responsible for the ecommerce platform since 2010. The tools I am proudest of there were never on anyone's wishlist. They were built because a process demanded them.
The largest is an email marketing engine I developed for the company's large-scale daily campaigns. It handles configuration, scheduling, sending, and detailed reporting, so a daily send is something you set up and review rather than something you babysit. That last part is the whole point. The process before was babysitting. The software exists to remove it.
Successories also sells customizable awards, and customizable awards involve proofs. So I built tools that streamline the customer proofing process. Faster proofing means less waiting for the customer and less overhead for the company. Again, the starting point was not "we need a proofing tool." It was a process with waiting built into it, and the waiting cost money on both sides.
How to describe your project to a developer
If you are a business owner about to talk to a developer, here is what I would ask you to bring instead of a feature list.
Walk through the process as it works today, start to finish, including the ugly parts. The workarounds and the "then I copy it into the other spreadsheet" steps are not embarrassing details. They are the specification.
Point at where the time goes. "This takes too long" is a great opening line, but the follow-up matters: which step, done by whom, how often. A task that takes ten minutes but happens fifty times a week is a better target than a painful task that happens twice a year.
Say what breaks. Where do mistakes happen? What falls through the cracks? Lost track of who has a piece of equipment, a proof that sat unanswered, a send that needed watching. Those failure points tell a developer what the software has to guarantee, not just what it should do.
Then let the features come out of that conversation. A good developer will propose them, you will recognize the ones that fit, and the ones that do not fit your process will never get built. That is the quiet benefit of this approach. Features that come out of a real process earn their place, and the wrong ones never make it onto the invoice.
I have been sketching software from sentences like "this takes too long" for a long time now, and I am still not tired of it. If your business has a process like that, one a spreadsheet is barely holding together, get in touch. Tell me about the process. We can figure out the features together.