SaaS is often the right answer
SaaS—software you use as an online service—is usually the better choice when a mature product already serves the need well. Email, video calls, accounting, payroll, standard customer relationship management, and ordinary project management rarely need to be rebuilt for one organisation.
A subscription buys more than features. It can include updates, support, and infrastructure that somebody else operates. A familiar collaboration tool may also be easier for people to learn than a new application.
Before commissioning software, check whether an existing product, better configuration, or a simpler process would solve the problem. An all-in-one platform can be a sensible choice when its parts work together in the way you need. A few unused features are not, by themselves, a reason to build an alternative.
When the workflow stops fitting the software
The difficulty often begins with a product that almost fits.
A request arrives in one service. Someone copies its details into a spreadsheet, asks a question in Telegram, updates another tool, and sends a separate message when the work is finished. An integration connects some steps. A colleague remembers the exceptions that nobody has written down.
The actual system has become:
SaaS + spreadsheet + messaging + manual copy-paste + another SaaS + integration tooling + undocumented human knowledge.
There is nothing inherently wrong with combining tools. The question is how much coordination the combination requires. If people repeatedly reconcile records, chase updates, or remember which screen holds the current status, the gaps between products have become part of the job.
In effect, the group may already have a custom system, assembled from products whose behaviour it does not control. The decision is whether that arrangement still works well enough.
The real cost of working around the mismatch
A small subscription fee can be good value. It can also be only one part of the cost of operating the workflow.
Look at paid seats, plan upgrades needed for one feature, and separate integration subscriptions. Then look at duplicate data, manual reconciliation, switching between tools, and training people to follow workarounds. Consider the effort of adapting the process whenever a product limitation gets in the way.
Vendor dependency matters too: how would a price change, removed feature, or difficult export affect the workflow? Moving to another system can require data cleanup, migration work, and retraining.
Apply the same scrutiny to custom software. Its cost includes understanding the problem, development, testing, hosting, support, security updates, and future changes. It can create dependency on a developer or platform. Owning the code does not make those responsibilities disappear.
Compare the options over the same period, including setup and transition effort. Use actual examples of manual work and mistakes rather than an optimistic savings estimate.
Custom software is not valuable simply because it is custom. It becomes valuable when fitting the software to the workflow costs less than continually fitting the workflow to the software.
That cost includes money, time, errors, and attention. Sometimes keeping the current tools is still the better answer.
What custom software can mean today
“Custom” does not have to mean “large”. It might mean:
- A Telegram Mini App or small private web application for one recurring task.
- A form with review, ownership, and status tracking, or a small order/status system.
- An internal scheduling tool or dashboard that brings the necessary information together.
- A small backend service, integration, import/export utility, or focused automation.
- A lightweight private tool for reminders and coordination.
These are possible formats, not a catalogue of existing BaptizedDragon products. The right format depends on where people already work and what they need to do.
A custom component can sit alongside SaaS. A request tool might send completed records to an existing accounting system rather than attempt to replace it. Often the useful part to build is the specific step that existing products handle poorly.
Why a focused tool can be more affordable today
Mature open-source components let developers reuse established building blocks instead of creating everything from scratch. More of the work can go into the part that is specific to your needs.
Managed databases, storage, and reusable services can reduce the supporting work a project needs. Hosting and deployment can also start small, with capacity and complexity added when they are needed.
AI-assisted development can reduce some implementation and iteration effort for well-defined work. The benefit varies with the task, and reviewing the result remains part of the work.
AI does not replace engineering judgment, product decisions, testing, security, operations, or maintenance. Someone still has to decide what should be built, check that it works, and keep it reliable.
None of this makes custom software automatically cheap. Narrow scope is the main reason a focused tool can become economically practical: one useful workflow means less to build, test, and maintain. These capabilities help most when the project stays small and clear.
Who is a good candidate?
The strongest signal is often: “We already have a process. We just run it manually.”
The process happens repeatedly, its basic rules are reasonably stable, and somebody can explain what happens from start to finish—including the common exceptions. People know the desired outcome but spend too much effort moving information between chats, spreadsheets, emails, and tools.
Existing products almost fit, yet the workarounds keep returning. Mistakes, duplicated work, or delays have a meaningful cost. One person or group can describe a small first version that would help and try it in real use.
That picture matters more than headcount or revenue. A small team can have a specific, well-understood need; a large organisation can still be unclear about what it wants. There should also be someone responsible for keeping the tool useful after launch.
Individuals, families, and small private groups
The same reasoning applies outside paid work. A person, household, family, group of friends, or small private community can have a recurring process that standard tools handle awkwardly.
A household might coordinate chores with an unusual rotation of responsibilities. A family might keep a record of important decisions and why they were made, or a small private archive. Friends might regularly collect preferences and availability for games, dinners, trips, or other shared activities. One person might need a particular combination of tracking and reminders.
A shared calendar, list, or poll should be considered first. If those work well, there is little reason to add another application. If the same awkward coordination returns each time, a Telegram Mini App, small private web application, or lightweight notification workflow may be enough.
Such a tool does not need to become a commercial product. It can serve only the people it was made for. Their willingness to use it, the privacy of their information, and the effort of maintaining it still matter.
The question is whether the problem happens often enough, matters enough, and can be made meaningfully simpler with a small tool. A personal need does not have to justify itself in terms of business revenue.
Who probably does not need custom software?
Custom development is probably not justified when:
- Existing SaaS covers the need cleanly, especially for a mature commodity function.
- The problem happens rarely or the process changes every week.
- Nobody can yet explain the workflow or agree on the desired result.
- Maintaining the tool would create more work than it removes.
- The first useful version cannot be defined narrowly.
- The main attraction is simply having something custom.
In these situations, document the process, simplify it, or try an existing tool first. Learning what is needed can be more valuable than committing it to software too early.
A practical decision checklist
Before evaluating a custom tool, ask:
- Does this workflow happen frequently?
- Is it reasonably stable?
- Are people manually moving or reconciling information?
- Do existing products require significant workarounds?
- Would removing those workarounds save meaningful time, errors, or attention?
- Can the first useful version be small?
- Can someone clearly explain how the workflow works today?
Several “yes” answers make custom software worth evaluating. They do not automatically make it the right choice. Compare a small proposal with better use of existing tools, including the ongoing responsibility each option creates.
Start with the smallest useful slice
Choose one complete loop. For example:
Incoming request → review → status → notification → completion.
A first version could collect the necessary details, show who is responsible, record the current status, and notify the requester when something changes. Define how a mistaken request is corrected and what happens if a notification fails. A small version should still handle its real job reliably.
It does not need to replace accounting, customer management, scheduling, and every spreadsheet at once. Keep the tools that already work.
Before building, agree on how people will recognise an improvement: fewer missing details, less chasing for updates, or less duplicate entry. Decide who will look after access, backups, and fixes. Make it possible to export the records if the tool is later replaced.
Use the first version in the real process. Let repeated needs discovered there guide the next features.
Fit the software to the need
SaaS, a focused custom tool, and a combination of the two can all be reasonable choices. The useful question is which arrangement makes this particular process easier to run and maintain.