Service · Web Applications
Your workflow is too specific for any app that already exists. Build the one that fits it exactly.
Every SaaS tool is built for the average customer; that's the most common version of your business, not the actual version. When your process has specific rules, specific roles, and data that needs to stay yours, a custom-built web application is the right answer. Client portals, internal dashboards, booking systems, intake workflows, custom CRMs: built in PHP to your exact spec, delivered with full source code and zero subscription fees. You own it outright.
What a custom web application requires to work reliably
A web application is software, not a website with a login button added. Building one correctly means getting these six things right before anything reaches your users. Fixing them after launch is far more expensive than doing them right during the build.
A database structure built around your specific workflow
The way your data is organized in the database determines whether the application can do what you actually need or whether every edge case in your real business becomes a workaround. A scheduling system for a medical practice organizes data completely differently than one for a cleaning company: different information, different relationships, different rules. Before any code is written, the data structure gets designed around your actual workflow. What records does the system store? What information does each record carry? How do they connect to each other? What rules govern them? Getting this right during the planning phase is the most important work in the entire project. Schema problems are cheap to fix before build starts; they are extremely expensive to fix six months after launch when real data is in the system.
A permission system that controls who can see and do what
Most business applications have several types of users: administrators who can manage everything, staff members who can see their assigned work, clients who can only see their own records, supervisors who can see across teams but not change settings. Getting these distinctions right is not just about the interface. The permission checks run on the server every single time someone makes a request. A user who figures out how to tweak a URL should not be able to view another client's data or trigger an action they are not supposed to perform. Permission enforcement happens at the code level on every action, not just in the menus the user sees. This is an architectural decision that gets designed in from the start, not a feature bolted on at the end.
An admin panel your staff can actually use
Every web application needs a control panel for the people running the business: a place to manage user accounts, view what is happening in the system, handle edge cases, configure settings, and run operations that regular users cannot. This is not a generic database viewer. It is instead an interface built specifically for how your team operates. When the admin panel is well-designed, your staff can handle day-to-day management without filing a support ticket every time something falls outside the normal flow. When it is not, every operational exception becomes a developer call. The admin panel gets the same design attention as the client-facing side of the application because the people using it every day are just as important as the customers.
Secure login and session handling built from scratch
Authentication for a custom application is a system designed specifically for that application, not a plugin or a copied snippet. Passwords are scrambled using a one-way process (called bcrypt) so that even if someone got access to the database, they could not read anyone's password. Login sessions are managed server-side and protected with settings that prevent them from being hijacked over an insecure connection or accessed by other websites. Repeated failed login attempts trigger a lockout to block automated guessing attacks. When a user logs out, the session is completely destroyed on the server. It's not just deleted from the browser. For applications handling sensitive information, additional controls like session timeouts after inactivity and optional two-factor authentication can be included.
Integrations with outside software that handle failures gracefully
Most real business applications connect to other software: Stripe or Square for payments, QuickBooks or Xero for accounting, Twilio for text messages, scheduling platforms for availability, email services for confirmations and notifications. These outside services occasionally go down, change their interfaces, or return unexpected errors. Integrations built without that in mind will crash the application when it happens, with a technical error page shown to your customer in the middle of a checkout. Each integration is built as a contained unit so that a failure in one outside service does not break unrelated parts of the application. Errors get caught and converted into clear, helpful messages for the user. The application handles the unexpected gracefully rather than falling apart.
Documentation that lets any developer take it over
At launch you receive a README that explains how the application is built, what it requires to run, what outside services it connects to, and how to deploy it to a server. The codebase follows consistent conventions that do not require knowing the original developer's habits to understand. A PHP developer who has never seen this project before should be able to read the documentation, set up a local copy, and understand the system well enough to make changes within a few hours. This is a hard standard, not a nice-to-have. Software that only one person can maintain is a liability. The goal is to hand you something you can own and operate independently, not something that creates a permanent dependency on ArdinGate.
What business owners who have done this before ask before they sign
Someone commissioning their first custom application evaluates based on portfolio samples and hourly rate. Someone who has done this before and gotten burned asks completely different questions. They have seen what happens when these things go wrong: a finished product that looked fine until real customers used it, a codebase the next developer refused to touch, a data model that needed a full rebuild three months in. These are the questions that separate the buyers who know what they are buying from the ones who find out later.
How do you make sure one customer's data never shows up for another customer?
In any application where multiple clients log in and see their own data, this is the most important question. It is not a design problem; it is a database query problem. Every time the system retrieves a record, the query has to filter by the logged-in user's ID, not just by the record's own identifier. A client record sitting in the database with a URL that contains its ID should not be viewable by another client who knows that ID. Ask a developer directly: how does your system verify ownership on every data retrieval? If the answer involves phrases like "we check the session" without explaining the specific mechanism, that mechanism has probably not been designed yet. Data isolation between clients is either correct by construction or it is not correct at all.
When do you design the database structure, and can I see it before you start building?
The database structure (the underlying organization of all your data) determines whether the finished application can handle your real workflow or just a simplified version of it. Bad structures get designed during the build rather than before it: tables get added as features are remembered, connections between records are expressed wrong, and the result is a patchwork system that fights itself. A developer who does discovery properly can produce a written-out structure showing every type of record, every piece of information it carries, and how records relate to each other. Before any application code is written, this needs to be designed. If a developer cannot show you this before the build starts, the structure is going to be figured out as they go. You will pay for those decisions in maintenance problems long after the project is closed.
What specifically happens to login sessions when someone logs out?
This is a question most buyers never think to ask, and it reveals a lot about how carefully an authentication system was designed. There are two ways to handle logout: delete the session cookie in the browser, or destroy the session record on the server. Only the second one actually logs the user out. If someone's session cookie is stolen (through a shared computer, a network interception, or any other way), and logout only deletes the cookie in that one browser, the stolen cookie still works until the session expires on its own. A correctly built system destroys the server-side session on logout, so that cookie is dead immediately regardless of where it is. Ask the developer to describe their logout mechanism specifically. The answer tells you whether the authentication system was designed or just assembled.
What does the application show my customer if a payment fails or an outside service goes down?
Every application that connects to outside software (payment processors, email services, scheduling platforms) inherits those services' failure modes. They go down. They hit rate limits. They return unexpected errors. An application that does not account for this will crash with a technical error page at exactly the wrong moment: while a customer is trying to check out, book an appointment, or submit an intake form. Ask a developer how their application responds when an outside service returns an error. The correct answer describes catching the error, logging it for investigation, and showing the user a clear message that explains what happened without a stack trace or PHP error in sight. If the answer is "we'll handle those as they come up," the error handling has not been designed.
How buyers actually go from "I need something built" to signing with a developer
People who commission custom web applications are not shopping the same way someone shops for a website. They already have a specific problem. They have usually tried to solve it with existing software and found that nothing fits quite right. By the time they land on a developer's service page, their question has shifted from "should I do this?" to "is this the right person to do it?"
The trigger is usually concrete: the spreadsheet tracking client projects gets too complex to maintain reliably. The SaaS tool almost works but forces the business to operate in a way that does not match how it actually runs. The manual process that was fine at twenty clients is breaking at eighty. At that point the buyer either tries one more round of SaaS alternatives (and concludes that none of them fit either) or goes directly to looking for a developer. Either way, by the time they find a service page, they have a problem defined and a strong sense that custom is the right direction.
From the service page, the evaluation is specific. The buyer is not reading about what technology stack the developer uses. They are looking for evidence that this developer has built something that resembles their problem before, understands the workflow domain well enough to ask intelligent questions about it, and has a process that will produce a deliverable rather than a half-finished codebase. Pages that speak to specific application types (client portals, booking systems, internal tools, custom CRMs) with enough detail to signal genuine experience convert this type of buyer. Generic "we build any web application" copy does not.
The funnel most commonly breaks at the first conversation. A buyer with a well-defined problem can be lost if the developer's response to their description is vague, or if a quote arrives without a corresponding spec that defines exactly what it covers. Serious buyers want to see that the developer can translate their workflow description into a concrete list of features, a data model, and a deliverable. This needs to happen before any money changes hands. The discovery call is where the project either wins or loses. The service page gets the buyer to the call. The call determines whether they sign.
Why the SaaS tool that almost fits is often worse than building from scratch
The pitch for using existing software is speed and cost: a monthly subscription is live immediately, a custom build takes weeks and costs more upfront. That argument is often correct, and a discovery call at ArdinGate will say so directly if the existing tools genuinely cover what you need. The problem is a specific class of business that does not fit into an average-customer product, and buyers in that class often do not realize it until they have spent months trying to make something work.
Off-the-shelf tools are designed for the majority of their subscribers. That means the features that ship are the ones most customers want, and the configuration options available are the ones most customers need. If your workflow differs in a meaningful way (a permission structure that does not match how you staff, a pricing rule the billing engine cannot express, a notification logic that requires branching the platform does not expose, a data relationship the product simply does not support), you end up choosing between compromising your actual process to fit the software or paying a developer to build workarounds on top of the subscription. At that point you are paying both the subscription and the developer, getting a patched version of neither, and still not owning anything.
No-code platforms extend what is possible without a developer, but they come with constraints that matter in production: performance you do not control, data stored in the platform's infrastructure rather than yours, no migration path if the platform changes pricing or shuts down, and visual logic builders that become impossible to trace as complexity grows past a certain point. A custom PHP application with a documented codebase and a database you own has none of those problems. The upfront cost is higher. The total cost of ownership over five years (no subscription, no per-seat fees, no ransom on your own data) is usually lower.
Pricing
Web application pricing is driven by the complexity of the workflow, the number of different types of users, and how many outside software systems it needs to connect to. Every project starts with a discovery call, not a quote based on a paragraph description. The call maps the workflow, defines the data model, identifies the user roles, and establishes the integration requirements. The quote is written against that spec.
Simple internal tools (one type of user, straightforward data, no outside software connections): $6,000–$11,000. Examples: an internal job tracker for a service company, a lead log with status and notes, a document management system for a small team, a custom estimating tool that automates a spreadsheet process.
Client and partner portals (people log in and see their own data, admin panel for your staff, layered permissions, several outside software connections): $16,000–$30,000. Examples: a client portal with document sharing and project status, a booking system with calendar integration and payment collection, an onboarding workflow with multi-step forms and email confirmation.
Complex multi-role applications (several different user types with distinct permissions, rich data models, extensive outside software connections, file handling, notification systems, or reporting dashboards): $40,000–$65,000. The range is wide because scope variance is high at this level. Each project is quoted after discovery.
All projects include full source code, database documentation, a deployment README, and a two-week post-launch window for bug fixes. Ongoing maintenance is available on a monthly retainer or per task. See the full web app cost breakdown →
Website pricing (if you need a marketing site alongside the app) →
Web application development questions
What kinds of web applications do you build?
Client portals where customers can log in and see their own invoices, project status, or documents. Booking and scheduling systems that manage appointments, send confirmations, and block out unavailable times. Internal dashboards where your staff tracks leads, jobs, or inventory in one place instead of across three spreadsheets. Custom CRMs built around your specific sales process. Multi-step intake forms that collect information from new clients and route it to the right person. Quote generators, field service management tools, employee time-tracking systems, and payment-connected checkout flows. The thing they all have in common: users log in, the system remembers their data, and different people see different things based on who they are. That is what makes something a web application rather than a regular website. Not sure which you need? See web application vs. website →
How much does a web application cost?
Every project is quoted after a discovery call. This is not a quote based on a paragraph you type into a form. The call maps out your workflow, who uses the system, what it needs to connect to, and what your data looks like. That is what drives the number. Roughly: simple internal tools where only your team logs in and there are no outside software connections start around $6,000. Client and partner portals where people log in and see their own data, with layered permissions and several outside software connections, run $16,000–$30,000. Complex multi-role applications with extensive integrations, file handling, and reporting start at $40,000 and go up based on scope. The primary cost drivers are the number of distinct user types, the complexity of your data model, and how many outside systems the application needs to talk to. Full cost breakdown with examples →
What is the difference between a web app and a regular website?
A regular website shows information and lets people contact you. A web application does things: it lets users create accounts and log in, stores information in a database, processes that information based on your business rules, and shows each user something different based on who they are and what they are allowed to see. A plumber's website lists their services and has a contact form. A plumber's web application tracks every job, shows each technician their schedule for the day, lets customers check the status of their repair, and sends the office manager a daily summary. If the thing you need involves people logging in, records being saved, or different users seeing different information, it is a web application. If it just needs to present your business and capture a lead, it is a website. Detailed comparison →
Can the web app connect to software I already use?
Yes, and this is one of the most common project shapes. If the software you use has an open connection point (most payment processors, accounting tools, scheduling platforms, and CRMs do), the application can talk to it: Stripe or Square for taking payments, QuickBooks or Xero for syncing invoices, Twilio for sending text messages, Mailchimp or Klaviyo for email lists, Calendly or Acuity for scheduling, Slack for internal alerts. It can also connect to your existing marketing website (sharing a database with it, pulling data from it, or running as a separate system that links in). If a mobile app is on your roadmap, the backend can be built from the start to support that rather than having to rebuild it later. That option is available through ArdinGate Studios, which handles iOS and Android.
Is my data safe? What happens to it after launch?
Your data lives in a database you own outright. At launch you get the full source code, the database structure documentation, and credentials to the hosting environment. Nothing about how the application is built creates an ongoing dependency on ArdinGate to access your own data. You can move it to a different host, hand it to a different developer, or keep working with me. Passwords are never stored in readable form. Login sessions are protected so they cannot be hijacked over an unsecured connection or read by other websites. When a user logs out, the session is destroyed on the server, not just deleted from the browser. File uploads, if the application handles them, are stored in a location that cannot be accessed directly from the internet; the system verifies who you are before handing over any file. Website security basics →
Will I be able to manage things myself, or do I need to call you every time?
Every application includes an admin panel built specifically for how your business operates. This is not a generic database browser, but rather a purpose-built interface where your staff can manage records, update information, view activity, handle edge cases, and configure settings without needing a developer. How much you can self-manage depends on what I define during discovery. If you want the ability to add users, change pricing, update content, or run reports without touching code, those capabilities get built into the admin panel. The goal is that your team handles day-to-day operation independently. You should need a developer for new features and meaningful changes, not for routine tasks that come up every week.
Can the app live on my existing website, or does it need to be separate?
Either approach works. The most common setup is a subdomain. The application lives at something like portal.yourcompany.com or app.yourcompany.com, which keeps it clearly connected to your brand while running independently from your marketing site. It can also run at a path on your main domain if the hosting setup supports it and the two systems can coexist without conflicts. A fully separate domain is an option for applications distinct enough from your main site to warrant their own identity. The right choice depends on what the application does, who uses it, and how you want it to feel relative to your main site. This gets sorted during the discovery call so the hosting and domain setup is correct from the start.
How long does it take to build a web application?
A simple internal tool with a clear workflow and no outside software connections runs 6 to 10 weeks from signed scope to launch. A multi-role client or partner portal with user accounts, dashboards, and a handful of integrations typically runs 3 to 6 months. A complex multi-role application with real-time features and heavier reporting can run 6 to 12 months or more. The biggest factor in timeline is how clearly defined the workflow is before build starts. When the workflow is mapped, the data model is designed, and the spec is written before the first line of code, timelines stay predictable. When requirements shift mid-build, they do not. The discovery process exists specifically to nail that down upfront rather than discovering scope problems after the project has started.
Why not just use an existing app or no-code tool instead of building custom?
For many workflows, an existing tool is the right answer. That gets said directly during the discovery call if it applies to your situation. Custom development is the right choice when the off-the-shelf tool almost fits but forces you to change how your business operates; when you are paying for a pile of features you don't use while missing the two or three features you need most; when the per-user or per-transaction fees become expensive as you grow; when your business rules cannot be expressed in the tool's configuration; or when your data needs to stay under your control for legal or competitive reasons. No-code platforms add the specific risks that your data lives in their infrastructure, the application has no migration path if they change pricing or shut down, and the logic builders become unmaintainable as complexity grows. Custom development has a higher upfront cost but no subscription, no per-seat fees, and no dependency on any vendor.
Do I own the code? Can I take it to another developer later?
You own everything: the source code, the database structure, all the data in it, and the hosting environment credentials. At handoff you receive the complete codebase in a repository under your control, plus a README that documents how the system is built, what it depends on, and how to deploy it. A PHP developer who has never seen this project before should be able to read that documentation, set up a local copy, and understand the system well enough to make changes within a few hours. You are not required to continue working with ArdinGate to keep the application running. SaaS tools keep your data as a way to keep you paying. A custom build hands everything back to you. This is not a selling point that gets softened; it is how the contract and the codebase are structured.
What does maintenance look like after the application launches?
Web applications need more ongoing attention than a static marketing site because they process live data and connect to outside software that changes. The main categories of post-launch work: keeping the application compatible as the hosting environment updates its PHP version (this happens every few years, not monthly), updating integration code when payment processors or other services change their interfaces, fixing bugs that only appear under real-world usage patterns that were not fully predictable during build, performance tuning as your data volume grows over time, and adding features as your business evolves. Ongoing maintenance can be arranged as a monthly retainer for applications that need fast response times, or handled per task for more stable applications. Because you own the code, you can also bring in any PHP developer for future work. You're not locked to ArdinGate.
Related services and guides: client portal development · payment integration · API development & integration · web app vs. website · web app cost guide · custom PHP development · website security basics
Have a workflow that needs its own software?
Tell me what you are trying to automate and where your current tools fall short. I will map the data model, define the user roles, and give you a fixed scope and price before any code is written.
Get a quote