Agency Suggested Building Our Tool as SaaS: What Does This Mean for Us?

Sounds like a classic agency play. They saw an internal operational problem that could be solved for 15-20k and turned it into a SaaS project to double their fee. Do you actually have a marketing team, customer support reps, or a sales pipeline ready to sell this to other businesses? If not, that entire multi-tenant backend will go to waste.

Keep this distinction in mind: 1) Internal tool: Built strictly around your specific workflows, zero unnecessary flexibility required. 2) SaaS: Demands complex configuration settings, tenant admin dashboards, and payment gateways to fit how *other* companies run their operations. If your primary goal is fixing your own operations, build for your own team first.

Three years ago, we set out with the exact same excitement for our own logistics business. We paid 55,000 dollars to have a SaaS architecture built. The product turned out great, but we never found the time to sell it to other companies; plus, our competitors didn't want to input their data into our system. In the end, we were just left paying an extra 600 dollars a month in server and maintenance costs.

Being a software vendor and being a wholesale food distributor are two completely different lines of work. Running a SaaS means getting phone calls in the middle of the night when a server crashes, dealing with billing disputes from external clients and handling non-stop feature requests. With your company's core focus being logistics, are you ready to spin up a software support center overnight? If the answer to that is no, ask for an internal tool instead of a SaaS.

If they build a multi-tenant architecture, will the database separation be logical or physical? Even if you never sell it externally, systems coded as SaaS have much more grueling maintenance, testing, and version release cycles compared to monolithic internal tools built for a single company.

Ask the agency for a revised quote: 'What would the budget and timeline look like if you build this exact same tool as a single-tenant web dashboard just for our internal use?' The quote will likely be cut in half. Seeing the two figures side by side will make the decision a whole lot easier.

agencies usually hype clients up like this just to add a flashy project to their portfolio but like imo dont bother, just get something siple built that gets the job done and save your time and money.

actually the idea isn't half bad; if there's a genuine gap in the industry it could become a fantastic side revenue steam down the road but tbh but you can cut down the budget by telling the agency 'let's use the first version internally for ourselves first—keep the database flexible for future scaling but skip modules like billing for now.'

This is exactly what we experienced. Just because everyone does it doesn't mean it's right.

If scope grows, either time or budget must grow. There is no third option. Of course, it varies if your situation is different.

I was thinking the same thing. Don't hesitate to ask; those who don't ask always pay more.

Taking notes for two weeks yields better results than a six-month estimate. Just leaving this note, it might be useful.

I have a question... Everything goes well for the first three months; problems arise in the fourth.

If you have questions, write them; I'll answer as best I can.

Three different views emerged, they all complement each other. anyway implementing a change request process doesn't slow things down, it speeds them up.

This is my opinion, I'm not claiming it's absolute truth.

Could you elaborate on that? Payment schedules should be tied to project phases, not calendar dates.

Of course, it varies if your situation is different.

It's rare to find an explanation this clear. Everyone rushing into what does saas development mean gets stuck at the same point.

Everything goes well for the first three months; problems arise in the fourth. This is my opinion, I'm not claiming it's absolute truth.

Let me summarize the topic, since several different answers were given. Processes without records never improve, because you don't know what to fix.

If you have questions, write them; I'll answer as best I can.

Could you elaborate on that? Implementing a change request process doesn't slow things down, it speeds them up.

I went through the same thing two years ago. If you get three different answers on a topic, the question was asked wrong.

That's all, sorry if I went on too long.

Let me speak from the other side; I'm on the supplier side. When we decide without measuring we always end up in the same place.

If you have questions write them; I'll answer as best I can.