Service businesses running on spreadsheets
Clinics, studios and field-service firms that track bookings in phone logs and sheets. You get a booking and records app with customer accounts, staff calendars and reminders in one database.
For service businesses, operations teams and agencies that need logins, stored data and role-based views in a browser-based app. We scope it first, then build it in stages.
Quick answer
Web application development is the process of planning, building and maintaining browser-based software with logins, stored data and role-based views. Examples include booking tools, customer portals and internal dashboards. Pugmarks Media scopes user roles, workflows and data first, then builds and tests the application in stages on a staging site before launch.
01Overview
Web application development is the work of designing, building and maintaining software that runs in a web browser and lets people log in, save information and complete tasks. Unlike a page that only displays content, a web application responds to what each user does and remembers it.
A concrete example is a booking tool for a physiotherapy clinic. Patients create an account, pick a time slot and receive a reminder. Reception staff see the full calendar, while practitioners see only their own appointments. All of it sits in one database instead of a phone log and a spreadsheet.
Three parts make that work. The interface is what people see and click. The backend holds the business rules, such as which slots are free. The database stores accounts, bookings and history, and permissions decide who can view or change each record.
Because the app is used through a browser, nobody installs anything, and updates reach every user at once. That suits internal dashboards, customer portals and approval systems, where several people need the same current data.
Web applications overlap with ordinary websites, and many projects combine both. A marketing site can sit beside a customer login area, for instance. If your site is mostly pages and a contact form, you may need web development rather than a full application. The right choice depends on whether users need to store data and take actions.
02Fit
Clinics, studios and field-service firms that track bookings in phone logs and sheets. You get a booking and records app with customer accounts, staff calendars and reminders in one database.
Teams that chase approvals by email and lose track of requests. You get role-based views, status tracking and an audit trail of who approved what.
Agencies sending reports and files by email each month. You get a login area where each client sees only their own projects, documents and updates.
Businesses whose support staff answer the same account, order or invoice questions repeatedly. You get a portal where customers check and update their own details.
Teams stitching together several subscriptions that do not share data. You get one custom application built around your workflow, with integrations to the systems you keep.
Founders who need a working first release, not a full roadmap. We split features into phases so the first version covers core roles and tasks, and the rest waits.
03Scope
04Process
6 steps. You always know what's next.
The same path for every engagement.
12-3 days (estimate)
We talk through your workflow, users and existing spreadsheets or tools. You share examples of current processes and access to any systems involved. You receive agreed goals and a list of open questions.
2About 1 week (estimate)
We document user roles, workflows, data and integrations in plain language. You review and correct it, and you sign off the scope. You receive a written requirements document that the build follows.
31-2 weeks (estimate)
We sketch each screen and the path every role takes through the app. You comment on layouts before any code is written. You receive wireframes and UX flows to approve.
41-2 weeks (estimate, overlaps design)
We choose the stack, design the database and decide on hosting, based on your roles, data volume and integrations. You confirm hosting and access preferences. You receive a technical architecture plan.
5Staging builds every 1-2 weeks (estimate)
We build in stages on a private staging site. You test each version with real scenarios and send feedback. You receive working builds with logins, stored data and role-based views.
61-2 weeks (estimate)
We run functional, browser and device checks, fix issues, then launch to production after your sign-off. You confirm final acceptance. You receive a testing and QA report and a live application.
05Deliverables
| Deliverable | What it is | Cadence | Starts in |
|---|---|---|---|
| Scoping call notes | Agreed goals, users and open questions from the first workflow discussion | One-time | Days 1-3 |
| Requirements document | Written scope of user roles, workflows, data and integrations for sign-off | One-time | Week 1-2 |
| Wireframes and user flows | Screen sketches and the path each role takes through the app | One-time | Weeks 2-4 |
| Database design | Structure for accounts, bookings, orders or requests | One-time | After sign-off of design |
| Staging builds | Working versions on a private staging site for your review | Every 1-2 weeks | After design approval |
| Role-based access setup | Separate logins and permissions for customers, staff and admins | One-time | During build |
| Testing and QA report | Functional, browser and device checks with issues logged and fixed | One-time, before launch | End of build |
| Launch and handover | Go-live on production with documentation of the work | One-time | After QA sign-off |
| Progress reporting | Summary of work done, open items and next steps | Monthly | First month after kickoff |
06Compare
Swipe to compare →
| Criteria | In-house | Typical agency | Pugmarks |
|---|---|---|---|
| Time to start | Depends on recruiting and onboarding | Depends on sales process and team availability | Starts with a scoping call, then a written requirements document |
| Specialization | Deep knowledge of your business, narrower technical range | Varies by agency, often broad service mix | Web, SEO and app work under one team |
| Reporting | Internal updates, format set by you | Varies by contract | Monthly reporting, plus staging builds to review |
| Cost model | Salaries, benefits, tools and management time | Project fee or retainer | Scoped per project; see the pricing page |
| Risk | Key-person dependency if a developer leaves | Handover and code ownership terms vary | Scope signed off in writing before build; testing report before launch |
| Flexibility | High control over priorities, limited by headcount | Changes often handled as change requests | Staged builds allow changes between reviews |
07Cost
Web application development cost depends mainly on scope: the number of user roles, how many workflows and screens the app needs, the complexity of the database, and any integrations with payment, email or other systems. Larger builds take more design, development and testing time. We price each project after the scoping call and requirements document, so the quote reflects written scope rather than a guess. See our pricing page for how we quote, or contact us to describe your project.
Package prices are published so you can compare before you call.
See all packages08Proof
Only results our clients have approved for publication. No made-up logos or numbers.
FAQ
Ask us directly. We reply with honest next steps, even if that means we're not the right fit.
Ask our teamMost web applications take from several weeks to a few months, depending on the number of user roles, workflows and integrations. Scoping and the written requirements document come first, then design, staged builds and testing. We give a timeline estimate after scoping, and it can change if the scope changes.
A website mainly displays content, while a web application lets users log in, save data and complete tasks. A booking tool or client portal remembers each user and shows different views by role. Many projects combine both, with a public site and a logged-in area.
You own the code we write for you once the project is paid in full. At handover you receive the source code and repository access. Open-source libraries we use stay under their own licences, so those terms still apply to those components.
Yes, in many cases. A web application can store records in one database, show each person only what they need and track approvals with an audit trail. We review your current spreadsheets and processes during scoping, then tell you what is practical to automate first.
Cost depends mainly on scope: user roles, workflows, screens, database complexity and integrations such as payment or email. We quote after the scoping call and written requirements, so the figure reflects agreed work. See our pricing page or contact us to discuss your project.
Yes, we offer a pilot. A pilot is a short, fixed-scope project that lets you see how we work before committing to more. Scope, deliverables and timeline are agreed in writing up front, and you have no obligation to continue afterward.
Yes, we can maintain and improve the application after launch. One-off development projects are priced per project with no ongoing term. Any later support arrangement is agreed separately, and we can explain the options once we understand how your team uses the app.
Changes are handled against the signed-off requirements document. We review each request, explain its effect on timeline and cost, and proceed only after you agree. Reviewing staging builds every 1-2 weeks (an estimate) helps catch changes early, when they are cheaper to make.
Get in touch
Start with a scoping call. We review your workflow, users and current tools, then agree the next step together.