Custom web application development: What it really takes

Custom web application development means designing, building and running browser-based software made for one organization's way of working, instead of adapting the organization to an off-the-shelf product. It takes a defined scope, a small team that covers backend, frontend and design, several months of iterative building and testing for most business apps, and a plan for maintenance after launch. The cost depends less on the number of screens than on the number of user roles, integrations and business rules the app has to handle.

We have built custom web applications in Managua since 2016, mostly on Laravel with React or Vue. This is what the work involves, from the first conversation to the years after launch.

When custom software is the right call

Before anyone talks about building, we ask whether the client should buy instead. If the need is a CRM, a help desk, an online store or a booking calendar that works like everyone else's, a SaaS product will be cheaper and better maintained than anything we could build at a reasonable budget.

Custom software makes sense when the workflow is the business: a package-forwarding company with its own rules for rates, pickups and billing, a marketplace with auctions and transport arranged per order, or a lending platform that has to read complex Excel reports. In those cases, the off-the-shelf tools either can't model the process or force so many workarounds that the team ends up running the business in spreadsheets next to the software.

We use a simple test. If every product the client has tried needed a spreadsheet beside it, custom is worth pricing.

What a project goes through

Every project we run goes through the same stages. Their length changes with the size of the product, and the order doesn't.

Scope

We write down the goal, the users and their roles, the flows each role needs with acceptance criteria, and what is out of scope. This takes a few working sessions with the client. Our article on defining a project scope covers the process in detail. We don't skip this stage, because every unclear requirement turns into rework later.

Design

For business software, design means flows and screens that work before they look good. We start with low-fidelity layouts for the main flows, review them with the people who will use the app, and then move to the final visual design. Admin panels and internal tools often use an existing component library with the client's brand applied, which saves weeks.

Build in short cycles

We build in one- or two-week cycles, and each cycle ends with something the client can use on a staging server. The first cycles go to the hardest flow, the one with the most business rules or the riskiest integration, because that is where the plan is most likely to be wrong.

Test and launch

Testing runs through the whole build: automated tests with each feature, code review, a staging check by the client before every release. Launch includes moving any existing data, setting up monitoring and backups, and a period where we watch the app closely while real users find what the tests missed.

Maintain

After launch, frameworks release security patches and new major versions, browsers change, third-party APIs deprecate endpoints, and the business asks for new features once people use the app. We still maintain several of the products we built. PickupHub, which lets players across Canada find and book drop-in sports games, is one. We built its web app, booking and payment flows and admin on Laravel and React, and we still maintain the platform.

What drives the cost

Clients often ask what a web app costs before there is a scope, and the honest answer is a range that is too wide to be useful. What moves the number is easier to explain.

Roles and permissions come first. An app with one type of user is a different project from one where customers, staff, managers and finance each see and do different things. On 1Click's package-tracking platform, permissions are set per action on packages, rates, pickups and billing, with an audit trail of every change. That level of control is valuable and it is real work.

Integrations come next. Every payment provider, accounting system, shipping API or SMS platform adds work for the connection itself, for error handling when the other side is down, and for testing against a sandbox that never behaves quite like production.

Data migration is the cost people forget. Moving years of records from an old system or a set of spreadsheets means cleaning them, mapping them to the new structure, and checking the result with the client. It is rarely the largest item, and it is often the one that delays launch.

Reporting, multi-language support, offline mode and a mobile app are each significant additions. Each one should come up in the scope, so nobody assumes it is included.

Small projects start at $5,000, and the price grows with the scope and the size of the team that builds it.

If the code lives in the vendor's accounts and you only get access, you are renting your own product.

The team you need

A custom web app needs people who can cover backend, frontend and design, and someone who owns delivery and talks to the client every week. On a small product that can be two or three engineers with one of them leading. On larger ones it grows, and design and QA may become separate roles.

We care a lot about the team staying the same. An engineer who built the billing module knows why it works the way it does, and replacing them midway costs weeks of reading code. We try to keep the same engineers on a product for as long as the client works with us.

The stack we use, and why

Our default is Laravel on the backend, React or Vue on the front end, and MySQL or PostgreSQL. We are an official Laravel Partner and have built on Laravel since 2016. We pick it because it ships with what most business apps need (authentication, queues, scheduled jobs, mail, file storage, a migration system) and because it is easy to hire for and hand over. For mobile apps that share the same backend, we use React Native.

For the client, the stack matters less than two questions. Can another team maintain this in five years, and does the client own it? We pick mainstream tools so the first answer is yes, and the next section covers the second.

You should own the code

In every project we build, the client owns the code and the intellectual property from the first commit, and the code lives in the client's own repository. If the client decides to bring development in-house or change vendors, they can do it without asking our permission.

Ask any vendor about this before signing, along with whose name the hosting and third-party accounts are in. If the code lives in the vendor's accounts and you only get access, you are renting your own product.

Questions to ask a development partner

When you compare vendors, these questions separate the ones who have shipped and maintained products from the ones who haven't:

• Who exactly will work on my project, and will they stay on it?
• How often will I see working software, and where?
• How do you handle a change in scope mid-project?
• What happens after launch, and what does maintenance cost?
• Where does the code live, and who owns the accounts?

Clear answers to those five tell you more than a portfolio does. We work with clients like ULANDU, a digital agency in Spain for which we built three of its clients' products on Laravel, and Decipher Credit, a commercial lending platform where we built data extraction from complex Excel reports. You can read what we did for each on our clients page.

If you are weighing a custom web application and want to know what yours would take, our product development team can help you scope it and build it.