Service · Web Applications
Custom web application development for your workflow
Subscription software is built for the average customer. If your business runs on its own rules and you want your data to stay yours, a custom web application fits: portals, dashboards, booking systems, or a custom CRM, built in PHP with no subscription. You get the full source code and 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
How your data is organized in the database determines whether the application fits your workflow or forces workarounds. A medical scheduling system organizes data completely differently than a cleaning company's: different records, relationships, rules. The structure is designed around your workflow before any code is written. Schema problems are cheap to fix before build starts, expensive once production data is in the system.
A permission system that controls who can see and do what
Most applications have several user types: admins, staff who see assigned work, clients who see only their own records, supervisors who see across teams but can't change settings. Permission checks run server-side on every request, not just in the menus shown, so tweaking a URL can't expose another client's data. It's architected from the start, not bolted on later.
An admin panel your staff can use
Every application needs a control panel for the people running the business: manage accounts, monitor activity, handle edge cases, configure settings. Not a generic database viewer, it's built for your team. A well-designed panel lets staff handle exceptions without a ticket; a poorly designed one makes every exception a developer call.
Secure login and session handling built from scratch
Authentication is built for each application, not bolted on from a plugin. Passwords are scrambled one-way (bcrypt); sessions are managed server-side, protected against hijacking, and locked out after repeated failed logins. Logout destroys the server session, not just the browser's. Sensitive applications can add inactivity timeouts and two-factor authentication.
Integrations with outside software that handle failures gracefully
Most applications connect to other software: Stripe, QuickBooks, Twilio, scheduling and email platforms. These occasionally go down or change interfaces, and an integration built without that in mind crashes mid-checkout. Each integration is a contained unit, so one failure doesn't break unrelated parts, and errors get caught and converted into clear messages instead of falling apart.
Documentation that lets any developer take it over
At launch you get a README covering how it's built, what it needs, and how to deploy it. Consistent conventions mean any PHP developer, unfamiliar with the project, can read the docs and start making changes within hours. That's a hard standard, not a nice-to-have: software only one person can maintain is a liability.
What to ask a developer before you sign
If this is your first custom app, it's easy to judge a developer on portfolio and rate alone. If you've been burned before, you ask different questions, because you've seen a product fall apart under real use, a codebase the next developer refused to touch, or a data model that needed a rebuild months in. These questions tell you what you're buying before you pay for it.
How do you make sure one customer's data never shows up for another customer?
In any multi-client application, this is the key question, a database problem, not a design one. Every retrieval must filter by the logged-in user's ID, not just the record's own identifier, so a guessable URL can't expose another client's data. Ask directly how ownership gets verified. "We check the session," with no specifics, means it probably isn't designed. Isolation is either correct by construction or not correct at all.
When do you design the database structure, and can I see it before you start building?
The database structure determines whether the application handles your workflow or a simplified version of it. Bad structures get designed during the build, not before: tables added as features are remembered, connections expressed wrong, a patchwork that fights itself. Proper discovery produces a written structure upfront. If a developer can't show you that before build starts, you'll pay for it later in maintenance problems.
What specifically happens to login sessions when someone logs out?
Few people ask this, but it reveals how carefully authentication was designed. There are two ways to handle logout: delete the browser cookie, or destroy the server session. Only the second actually logs you out. A stolen cookie still works until it expires if logout only clears the local copy. A correctly built system kills the server session immediately. Ask the developer to describe their logout mechanism specifically.
What does the application show my customer if a payment fails or an outside service goes down?
Every application connecting to outside software inherits its failure modes: services go down, hit limits, or error out. An application that ignores this crashes with a technical error page mid-checkout or mid-booking. Ask how it responds to an outside-service error: the right answer describes catching it, logging it, and showing a clear message. "We'll handle those as they come up" means it hasn't been designed.
Why the SaaS tool that almost fits is often worse than building from scratch
The pitch for existing software is speed and cost, live now versus weeks and more upfront. That's often correct, and discovery will say so if existing tools fit. The problem is a class of business that doesn't fit an average-customer product, often unrealized until months of forcing something.
Off-the-shelf tools serve the majority: features and configs match what most customers want. If your workflow differs meaningfully, permissions that don't match your staffing, a pricing rule the billing engine can't express, a data relationship it doesn't support, you either compromise your process or pay a developer for workarounds atop the subscription. Either way you pay both and own nothing.
No-code platforms extend what's possible without a developer, but with production constraints: performance you don't control, data in their infrastructure, no migration path if pricing changes or they shut down, and logic builders that become untraceable as complexity grows. A custom PHP application you own has none of those problems. Upfront cost is higher; five-year cost is usually lower.
Pricing
Pricing is driven by workflow complexity, user-type count, and outside-system connections. Every project starts with a discovery call, not a form description: the call maps workflow, data model, roles, and integrations, and 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.
Basic client portals (secure login, documents, and status for your clients, plus a simple admin for your staff): $5,500–$10,000.
Full 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 invoices, messaging, and payments, a standard-tier custom CRM with role permissions and reporting, 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 30-day post-launch window for bug fixes. Ongoing maintenance is available on a monthly retainer or per task. Managed hosting is billed monthly: Core $60/mo, Care $100/mo, or Priority $180/mo. See the full web app cost breakdown →
Get a number for your app now: Cost estimator →
Website pricing (if you need a marketing site alongside the app) →
Web application development questions
What kinds of web applications do you build?
Common project types:
- Client portals where customers 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
What they have in common: users log in, the system remembers their data, and different people see different things. That's what makes it a web application rather than a 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, not a form description. The call maps your workflow, users, connections, and data, that drives the number. Roughly: simple internal tools (only your team, no outside connections) start around $6,000. Basic client portals (logins, documents, status) run $5,500–$10,000; full client and partner portals (layered permissions, several outside connections) run $16,000–$30,000. Complex multi-role applications with extensive integrations, file handling, and reporting start at $40,000 and scale with scope. Cost drivers: user-type count, data complexity, and outside-system connections. Full cost breakdown with examples →
What is the difference between a web app and a regular website?
A website shows information and lets people contact you. An application does things: accounts, login, a database, business rules, different views per user. A plumber's website lists services with a contact form; a plumber's app tracks every job, shows technicians their schedule, lets customers check repair status, and emails a daily summary. Login, saved records, or per-user views make it an application; presenting your business and capturing a lead makes it a website. Detailed comparison →
Can the web app connect to software I already use?
Yes, a very common shape. If your software has an open connection point (most payment, accounting, scheduling, and CRM tools do), it can talk to it: Stripe, QuickBooks, Twilio, Mailchimp, Calendly, Slack. It can also connect to your marketing site, sharing or pulling data. A mobile app on your roadmap can be built for from the start 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 source code, documentation, and hosting credentials, no ongoing dependency: switch hosts or developers anytime. Passwords are never stored readable. Sessions resist hijacking, and logout destroys the server session, not just the browser's. File uploads sit where the internet can't reach directly; the system verifies you first. 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 for your business, not a generic database browser, where staff manage records, view activity, and configure settings without a developer. Self-manage scope gets defined during discovery: adding users, pricing, content, reports, whatever you need. The goal is a team running day-to-day independently, calling a developer only for new features, not routine tasks.
Can the app live on my existing website, or does it need to be separate?
Either approach works. Most common is a subdomain, portal.yourcompany.com or app.yourcompany.com, connected to your brand but running independently. It can also run at a path on your main domain, if hosting supports it, or on a fully separate domain for applications distinct enough to warrant their own identity. The right choice depends on what the application does and how it should feel relative to your main site, sorted during the discovery call. If you also want it on your customers' phones as a native iOS/Android app, you can get that built on the same backend through ArdinGate Studios, and its app cost estimator gives you a ballpark.
How long does it take to build a web application?
A simple tool runs 6 to 10 weeks from signed scope to launch. A multi-role portal usually runs 3 to 6 months. A complex application with real-time features runs 6 to 12 months or more. The biggest factor: how clearly the workflow is defined before build starts. Mapped and spec'd upfront keeps timelines predictable; shifting requirements mid-build don't. Discovery exists to settle that before the project starts.
Why not just use an existing app or no-code tool instead of building custom?
For many workflows an existing tool is right, and I'll say so during discovery. Custom makes sense when the off-the-shelf tool forces an operational change, when you pay for features you don't use while missing ones you need, when per-user fees get costly, or when data needs to stay under your control. No-code adds risk: data in their infrastructure, no migration path if they shut down, unmaintainable logic builders. Custom costs more upfront but no subscription, no per-seat fees, no vendor dependency. Side-by-side numbers: Airtable vs. a custom app and Bubble vs. a custom app.
Do I own the code? Can I take it to another developer later?
You own everything: source code, database, data, hosting credentials. At handoff you get the codebase in a repository you control, plus a README covering how it's built and deployed, enough for any PHP developer to set up a local copy and start changes within hours. You're not required to keep working with me. SaaS keeps your data as leverage; a custom build hands it all back, by contract.
What does maintenance look like after the application launches?
Applications need more attention than a static site because they process live data and connect to software that changes. Post-launch work: keeping pace with PHP updates, adjusting integrations as services change, fixing real-world bugs, tuning performance as data grows, adding features. Maintenance runs as a monthly retainer or per task. Managed hosting is billed monthly: Core $60/mo, Care $100/mo (adds one hour a month of content edits), or Priority $180/mo. New features are quoted separately. You own the code, so any PHP developer can pick up future work.
Can AI be added to my application?
Yes. If you already use an AI service (OpenAI, Claude, Gemini, or any provider with an API), it can be connected to your application to summarize notes, draft emails and replies, or answer questions about your records. You keep your own account and pay the provider directly for usage, and nothing it suggests changes your data until someone on your team approves it. Adding it runs $2,500–$6,000.
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. You get a mapped data model, defined user roles, and a fixed scope and price before any code is written.
Get a quote