WordPress is a capable platform, and I build on it constantly. But it is a content management system, not an application framework. When the core requirement is data processing, user authentication, multi-step workflows, or real-time interaction — a standalone custom web application is usually the more honest answer. Forcing those requirements into a CMS adds layers of complexity that compound over time and rarely age well.

How to Know You Need a Web App, Not a CMS

The clearest signal is when you find yourself trying to bend a CMS into doing something it was never designed for. Booking engines, client portals, calculators with logic branches, intake workflows with role-based access — these are application problems. Fitting them into WordPress is possible but rarely clean, and the maintenance cost adds up.

A custom web application lives at its own URL, connects to its own data store, and does exactly what your workflow requires. Nothing more. The absence of a general-purpose content layer is a feature, not a limitation. There is no plugin ecosystem to manage, no theme compatibility to worry about, no Gutenberg update to navigate. The application does one thing and is maintained as a focused codebase.

Secondary signals worth noting: you need fine-grained permission systems that WordPress roles cannot model, you need data relationships that a relational database handles better than WordPress post meta, or you need background processing that a request-cycle CMS architecture is not designed for. Any of those point toward a purpose-built web application.

What I Build — and What I Do Not

I focus on marketing-adjacent custom web applications: tools that sit between your marketing layer and your operations layer. Lead intake systems, proposal generators, client reporting portals, automated onboarding flows. These are the gaps where a business is doing manual work that a well-scoped application can eliminate.

Concrete examples of what I have built in this category: a client portal that lets agency customers log in, view project status, approve deliverables, and download files — replacing a shared Google Drive and a weekly status email. A proposal generator that takes a sales rep through a structured intake form and outputs a formatted PDF proposal, eliminating four hours of manual formatting per deal. An automated onboarding flow that assigns tasks, sends timed email sequences, and tracks completion without a human touching it after initial setup.

I do not build consumer-scale social platforms or SaaS products with venture-backed feature roadmaps. The scope I work in is deliberate: applications that solve a specific, documented business problem for a single organization or a small defined user group. That constraint is what makes the projects finishable and maintainable.

When a headless approach makes sense — for example, pairing a custom front end with a WordPress content backend — that is a different conversation. See headless WordPress for when that tradeoff is worth it. When the need is specifically for an API integration between existing systems rather than a net-new application, API integration services is the more relevant track.

The Technology Stack Question

Stack choice follows requirements, not preference. For most of the web applications I build, the priority is maintainability over novelty. A business owner should not need me on call to make basic changes two years after launch. I choose frameworks and architectures accordingly, and I document the reasoning in the codebase.

What that looks like in practice: server-rendered applications for workflows where SEO matters and real-time interaction is not the core requirement. API-backed frontends for applications where the data layer is shared across multiple surfaces. Lightweight frameworks over heavy ones when the feature set does not justify the complexity. Postgres over exotic data stores when relational data is what the problem actually requires.

I do not chase new frameworks. The frameworks I use are ones I understand well enough to debug without Stack Overflow at two in the morning. That matters more than using the current popular option.

Scoping a Custom Web Application Build

The most common mistake I see is starting with a feature list. A feature list is not a scope. A scope describes who does what, when, and what the system does in response. Before any development starts on a project at Salterra, we map the workflow in plain language. Every screen, every decision point, every data input and output. That document becomes the specification.

  • What does the user do first?
  • What does the system do in response?
  • Where does data go and who can see it?
  • What happens when something goes wrong?

Those four questions surface the complexity that feature lists hide. A feature list says "user uploads a file." A scope document says what file types are accepted, what the size limit is, where the file goes, who gets notified, what happens if the upload fails, and what the user sees in each case. That is the difference between a project that finishes on time and one that expands indefinitely.

Scoping typically takes two to four hours of conversation and produces a written document before any development starts. That document is fixed-price quoted. Changes to scope after development starts are documented as change orders with a revised price and timeline before work continues. See how to scope a software project for what that process looks like from the client side.

Realistic Costs and Timelines

Custom web applications start at $9,500 for straightforward builds — a single workflow, a handful of screens, no complex integrations. Most projects land between that floor and $30,000 depending on the number of user roles, the complexity of the data model, and the depth of third-party integrations required.

Timeline follows scope, not a calendar. A well-scoped eight-screen application with one integration typically takes six to ten weeks. Add a complex permission system, multiple integrations, or a reporting layer and that extends. Rushing a web application build produces technical debt that costs more to fix than the time saved — I do not do it and I will say so directly if a timeline is not realistic for the scope.

The ongoing cost after launch matters too. Applications need maintenance: dependency updates, hosting, occasional bug fixes as edge cases surface in real use. I build with that reality in mind — no architecture choices that create an ongoing maintenance burden the client cannot afford.

For a structured comparison of custom build cost against no-code alternatives, custom software cost has the numbers worth running before deciding.

When a Custom Web Application Is the Wrong Answer

Custom web application development is expensive relative to SaaS and no-code alternatives. If your workflow fits inside an existing platform — even imperfectly — the economics of custom development rarely pencil out in the short term. The break-even point is usually three to five years of subscription costs, or a workflow gap significant enough that the SaaS friction creates its own measurable cost.

I recommend no-code or SaaS tools first for: standard CRM workflows, email automation, simple internal databases, basic client communication. GoHighLevel, Airtable, HubSpot, and similar platforms exist because most workflows are common enough that someone already built the tool. Use them when they fit. The no-code vs. custom software comparison is worth reading before starting any application project.

The software development overview covers where custom web application work fits alongside other types of builds — worth reading if you are still figuring out what kind of project you actually have.