You can build a useful landscaping app with AI. The harder question is whether you want to run it.
An estimating calculator, a crew scheduler, a customer portal: tools that once needed a developer can now start with a description and a few evenings of work. That's a real opportunity for landscape companies. You know your operation better than anyone, and sometimes a small tool built around your process is exactly what you need.
The decision changes when that tool becomes something your business depends on. Getting the first version working is one milestone. Keeping it available, maintaining its connections and protecting the information inside it is ongoing work.
What one week in October makes clear
Two events on October 21, 2026, put that ongoing work into perspective.
Railway disclosed a security incident. The hosting platform said an unauthorized party may have accessed customer environment variables, including some decrypted contents. Those variables can contain API keys and database credentials. Railway recommended that all users rotate stored secrets and review connected-service logs as a precaution. For an affected app owner, the work extended beyond the host to whatever those credentials could access. Read Railway's disclosure.
PHP released urgent security fixes. Its maintainers patched two critical vulnerabilities that, under the right conditions, could let an unauthenticated attacker execute code on a server running PHP. They urged users to update. Operators needed to identify affected installations and make sure the fixes were applied. Read the PHP Foundation's release.
Our incident response at Grounds Manager. We use Railway to host some of our products, so this was relevant to our own operations. Responding to issues with the services behind our software is part of the responsibility we take on as a software company. Customers should be able to focus on running their businesses while we handle that operational work.
Neither event meant every custom app was affected. Your exposure depends on the services and software you use. A managed provider may handle some updates for you; other actions still fall to whoever operates the app.
The useful question is: who notices, who responds, and who checks that everything works afterward?
Good reasons to build
Building makes sense when the purpose is narrow and the consequences of failure are manageable.
- A calculator with no stored customer data. A mulch-volume tool, a mowing production-rate calculator or a way to compare equipment costs.
- A local tool with a fallback. A tool that runs on your computer, with information you can recover and a process you can use if it stops working. Keeping it offline reduces exposure; it doesn't remove the need to protect the computer.
- A prototype of your process. Build a rough estimating workflow to work out what you need before you choose a product or hire someone to develop it.
- A specific workflow. A small tool that solves a problem existing products don't handle, with a clear owner and a sensible maintenance plan.
The common thread is a limited job, limited exposure and a way to keep working when something breaks.
Where the commitment changes
Custom software can handle these things, but each one raises the standard you need to meet.
- Customer information. Property addresses, manager contact details, gate codes and alarm codes deserve different access rules. Collect only what you need and decide who can see it.
- Invoicing and payments. QuickBooks connections, payment services and financial records add permissions, error handling and reconciliation work. A working payment screen is only part of the process.
- Vendor portals and integrations. Credentials for ServiceChannel or another portal carry whatever access those credentials grant. You need to know where they're stored, how they're limited and how to revoke them.
- Crew access from the field. Lost phones, shared logins, staff changes and poor signal all need to be considered. You need a way to remove access without disrupting everyone else.
- Work that cannot wait. If the scheduler stops working in peak season, someone has to restore it. If that's you at 10 p.m. after a full day, include that time in the decision.
What ownership actually includes
Before you compare a subscription with the cost of building, include the work that continues after launch.
AI can help with this work. You still need someone who can judge the changes, act on alerts and verify the outcome.
If you build, start with these basics
Treat these as a starting point, not a complete security plan. A system handling payments, sensitive customer information or essential operations may need experienced technical help.
How I would make the decision
Start with three questions: what happens if this tool fails tomorrow, what information could it expose, and who is responsible for putting it right?
If it's a small internal tool with a workable fallback, building may be a good use of your time. If it's the system your crews, customers and cash flow depend on, compare the full ownership cost with a product that already covers the work you need. Building can still be the right choice if you have the capacity to operate it.
You can also do both: use established software for core operations and build small tools around the parts of your process that are different. Keep those connections limited and documented.
Buying software deserves the same scrutiny. Ask the vendor how updates are handled, how access and integrations are protected, what recovery and support look like, and whether you can export your records. A subscription is not a security guarantee. Those questions apply to Grounds Manager too.
My recommendation: build the small tools that make your operation better. Be deliberate about taking on the software your whole company relies on.
If you'd rather put that time into running your operation, you can explore what we're building at Grounds Manager.