The question is simple to ask and easy to answer with a product name. Answer it by looking at the work instead. Buy a product when the step your office depends on survives inside it. Build when that step keeps falling out. A technology stack, a feature list, and a slogan are not a starting point. A workflow you can describe out loud is.
Software is worth building when you can describe the workflow, whether that ends up as a web application, custom software, or an internal tool that replaces a spreadsheet. If you cannot, a ready-made product is usually the better first move. This guide walks through how to tell which situation you are in, using a check we run before any project begins at Triwave Consulting. It is not a result we are claiming for anyone. It is simply the right order of questions.
Takeaways
- Name the item your office passes from one person to the next before you name a tool.
- Use one test: a person who does the work can point at the weekly task without naming a product.
- The common wrong start is choosing a language, a host, or a feature list before the task fits in a sentence.
- Use this article to make the decision, and use the service page to ask for the work.
The Choice in Plain Terms
Put the two options side by side without a scoreboard. One is to keep what you have, or to adopt a ready-made product shaped like it. The other is to change the shape of the tool so the step stops falling out. You are not choosing a philosophy. You are choosing where the item your office passes from one person to the next lives on an ordinary day.
If it lives cleanly where it is, stay. If it lives in an inbox and a shared spreadsheet that only one person will edit, then staying has a cost you can describe without a pile of opinions. Take the situation of an owner caught between a polished product demo and a custom build, unsure which one keeps the step the office runs on. The job here is concrete: choose a product when the step survives inside it, and a build when the step keeps falling out.
If you came here for a different job, such as picking a website platform or hiring a developer, this page will not be much help, and that is on purpose. A project aimed at two goals at once usually serves neither.
When Buying or Staying Fits
The first path fits when the test already passes. A person who does the work can point at the weekly task without naming a product, and that sentence is the whole green light. You do not need a second product, a custom build, or a new platform to feel modern. Changing tools because a demo looked polished means choosing a language, a host, or a feature list before the task fits in a sentence, and it gives you a new place to be confused.
Stay when the person who does the work can finish the item without a side path. Staying is a decision, and it deserves the same respect as a build. Write down that you stayed and why, so next month's demo does not reopen a question you already closed.
The second path fits when the first one keeps dropping the step. You will know because the real work happens in an inbox and a shared spreadsheet that only one person will edit. People are polite about this. They say the tool is fine, and then they keep the side path alive, because the side path holds the item the office actually moves. Believe the side path. It is your specification, written in behavior. A longer feature list that still needs the side path has not solved the problem, only decorated it. Move on when you can point at the dropped step and say it belongs to the business, not to a preference about labels.
Use this list as a single pass, not as a poster:
- Write down the step the office cannot afford to lose.
- Try to finish that step in the option you already have.
- Notice whether you reached for a side path.
- If you did, the other option is the one that has to hold the step.
- If you did not, stay where the step already survives.
When Building Fits
Feature checklists hide this. They award a point for every box a product can tick and no point for the step your office actually runs. A box labeled custom fields, automation, or analytics often means you will rebuild the same inbox and shared spreadsheet inside a new logo.
Ask for one real item to be finished in the option you are testing, and watch the hands rather than the slide. If someone leaves the system at the awkward moment to fix it elsewhere, the checklist has already lost, no matter how many boxes were green. Do not average that moment away. It is the comparison.
The same checks sit in a table so you can see the fork at a glance. Every cell is a judgment you can make from the work in front of you. None of them is a score, a price, or a borrowed result.
| Question | Buy or stay (first path) | Build (second path) |
|---|---|---|
| What you are protecting | The way the work happens today | The step that keeps falling out |
| When it fits | A person who does the work can point at the weekly task without naming a product | The current setup is an inbox and a shared spreadsheet that only one person will edit |
| When it fails | You are choosing a language, a host, or a feature list before the task fits in a sentence | You cannot name the item the office moves from one person to the next |
| What you still do | Watch the first real item go through | Say the stance out loud before you switch |
What a Checklist Hides
Decide in one sitting if you can. Write the step down. Try to finish it where you are. If you finish it, stop shopping. If you cannot, the other path is the one to discuss, and the discussion is about that single step. Avoid opening five trials and a custom estimate in the same week, because you will remember the best demo and forget the step. One honest pass is enough.
Hiring, if the second path turns out to be a build, a connection, or a report, comes after this choice. This article ends when the direction is clear.
Triwave Consulting will not pretend both paths are a tie that a case study could break. We do not publish those numbers, and we will not invent one to close a sale. What we can do is listen for the step during Initial Contact and decline a plan that ignores it. Detailed Discussion is where the chosen path gets a record, a person, and a boundary. Implementation follows the path you picked, and it changes if the path was described wrong. The page for that work is Software Development. Use it when you already know which way you are leaning and want that tested against the work, not against a slogan.
How to Decide This Week
Hold the choice to one step you can watch. If that step survives where the work already happens, stop shopping. If it falls out, the other path has earned a conversation, and only that path. A second feature is not a reason to reopen a choice you have already watched play out.
On this site the work splits across Web Applications, Custom Software, and Internal Business Tools. This article stays with the decision they share, and each of those pages is the offer for its own shape. As a rough guide, Web Applications fits when people outside your office need to use the tool. Custom Software fits when the whole process is unusual enough that nothing off the shelf matches. Internal Business Tools fits when the job is replacing a spreadsheet or inbox your own team relies on. Choose one of those pages if the shape is already clear, and stay here while you are still working it out.
Before you close the tab, walk through one ordinary week. Find the item people are careful with, and notice what happens when a second person needs it: does someone forward it, retype it, or hold it back? That moment is the subject. If the test already holds, your week does not need a new shape. If it fails, write the failure in your office's own words, and resist translating it into a feature request.
Questions
What If the Current Option Is Close?
Close is not the test. The test is whether the step survives. If the real work is still an inbox and a shared spreadsheet that only one person will edit, then close means the step is still outside the system. Finish one real item inside the option before you call it close enough.
Should a Feature Checklist Decide?
No. Checklists reward breadth, and your decision comes down to a single step. A long list of ticked boxes can hide a missing step. Watch the item move, not the boxes.
Can You Switch Later?
Yes. Choosing a direction this week is not a vow. It is a refusal to pretend you have no information. Revisit the choice when the record or the workflow changes, but not every time a demo looks shiny.
Is Configuration the Same as a New Build?
No. Configuration keeps you inside a product. A build, a connection, or a new report is a different kind of work. Avoid calling a setting "custom," and do not fear configuration when the test already passes.
What If Both Options Still Need a Person?
Both will. Software is worth building when you can describe the workflow, whether it becomes a web application, custom software, or an internal tool that replaces a spreadsheet, but a person stays accountable either way. The comparison is about where the record lives, not about removing people from the business.
Conclusion
You came with a question about software development, and the aim here was a check rather than a pitch. A project starts when the workflow, the people who touch it, and the neighboring system can be said out loud. A stack, a feature list, and a slogan are not a start. Avoid the wrong start of choosing a language, a host, or a feature list before the task fits in a sentence. The service page can take the conversation from here. When your description is real, you already know what to say first.
When you have picked a direction and want it tested against the work, Speak With Us.
