Web applications
Web applications your customers and staff use every day
We design, build and run browser-based software: customer portals, internal tools, dashboards and SaaS products. Built in TypeScript, deployed every week, committed to your repositories.
Who it's for
Clients usually come to us for web applications in one of these situations.
You're launching a SaaS product
You need sign-up, team accounts, roles and subscription billing from day one, on an architecture that won't need rewriting after the first hundred customers.
A core process runs on spreadsheets
Approvals, schedules or inventory live in shared sheets and email. Mistakes are hard to trace and only a few people understand the formulas.
Your app has outgrown its first build
Pages are slow, every change breaks something else, and the developer who wrote it has moved on. You need it stabilized without stopping new work.
What we build
Most web work we take on falls into one of these shapes. Many projects mix two or three of them, and the subscription lets you move between them as priorities change.
- Customer portals
- Accounts, billing history, document downloads, support tickets and self-service settings, connected to the systems you already run.
- SaaS products
- Multi-tenant apps with sign-up, team invitations, roles, subscription billing through your payment provider and an admin console.
- Internal tools and dashboards
- Operations screens that replace spreadsheets: approvals, scheduling, inventory, reporting and exports your finance team can use.
- APIs and integrations
- REST and GraphQL APIs, webhooks, and connections to CRMs, ERPs, payment processors and data warehouses.
- Marketing sites with an app behind them
- Fast, accessible public pages that share a design system and login with the product, managed through a headless CMS.
- Rebuilds of legacy apps
- Incremental replacement of aging PHP, Rails or jQuery front ends, screen by screen, without a long freeze on new features.
How we approach it
Every request moves through the same steps, inside your weekly release cycle.
- 01
Spec before code
Each request gets a short written spec with acceptance criteria and screens. You approve it before work starts.
- 02
Preview on every pull request
Every change gets its own preview link so you can click through it before it merges.
- 03
Tested and reviewed
Automated tests run on each change, and a second engineer reviews every pull request.
- 04
Weekly production release
Approved work ships on a fixed weekly cadence, with written release notes and a short demo video.
Typical timeline
Engagement timeline
A typical schedule for the first production release of a new web application. Existing codebases begin with a review in week one instead.
About 12 weeks to a first production release
Weeks 1 to 2
Discovery and spec
Users, workflows and data are mapped, and the first release is written up with acceptance criteria.
Weeks 2 to 4
Design of core flows
Screens for the main workflow and admin view, reviewed as a clickable prototype.
Weeks 3 to 5
Foundations
Authentication, data model, CI pipeline, staging and production environments, and error tracking.
Weeks 5 to 10
Core workflow build
Features shipped weekly to staging behind preview links, each with tests and code review.
Weeks 9 to 12
Hardening
Accessibility and performance passes, security review of auth and access control, and monitoring.
Week 12
Production release
Go-live with a rollback plan, then the weekly cadence continues against your roadmap.
Typical for a first release with one main workflow on a Starter or Growth plan. Integrations with older systems and data migration are the usual reasons a schedule grows.
What you get every week
Releases happen on a fixed day each week. Monday starts with a queue check; Friday ends with these in your inbox and your shared channel.
Preview links
Every pull request deploys to its own URL. You click through changes with realistic data before they merge.
Production release
Approved work ships on a fixed weekly day, with written release notes that link each change to its request.
Demo video
A short recording of what shipped and how it behaves, including edge cases we tested.
Queue and spec status
An updated view of what's in progress, what's waiting on your approval, and the specs for the next requests.
Quality standards
The targets we hold this work to, and how we check them. These are our commitments for how the work is done, not certifications.
- Code review
- Our targetEvery pull request is reviewed by a second engineer before it merges.
- How we checkBranch protection rules in your repository make review a requirement, not a habit.
- Automated tests
- Our targetUnit and integration tests for new code; end-to-end tests for sign-in, payments and other critical flows.
- How we checkTests run in CI on every pull request, and a failing test blocks the merge.
- Accessibility
- Our targetWCAG 2.2 Level AA as the target for new screens and components.
- How we checkAutomated axe checks in CI plus a manual keyboard pass on each new screen.
- Performance
- Our targetCore Web Vitals in the "good" range for public pages, and a response-time budget agreed for key API endpoints.
- How we checkLighthouse checks on preview builds and response-time monitoring after release.
- Application security
- Our targetReviews of authentication, input handling and access control informed by the OWASP Application Security Verification Standard.
- How we checkA security checklist in code review, plus automated dependency and secret scanning.
- Environments
- Our targetEvery change passes staging before production, and database migrations can be rolled back.
- How we checkEnforced by the deploy pipeline; nobody deploys from a laptop.
Typical deliverables
What you can expect to have in hand, in accounts and repositories you own.
- Source code in your GitHub or GitLab organization
- Written spec and acceptance criteria per request
- Automated test suite and CI pipeline
- Accessibility checks against WCAG 2.2 AA
- Release notes and a demo video every week
- Architecture notes and a README new engineers can follow
Illustrative example, not a client case study
Example engagement
An operations team replaces its scheduling spreadsheet
Imagine a regional services company that schedules field crews from a shared spreadsheet. Double bookings happen weekly, and the office manager is the only person who knows how the sheet works.
Weeks 1 to 2
Map the real process
Calls with dispatchers and the office manager document how jobs are assigned today, including the workarounds the sheet doesn't show.
Weeks 2 to 4
Prototype the schedule board
A clickable prototype of the board, job detail and crew views is reviewed by the dispatchers who will use it every day.
Weeks 4 to 9
Build with roles and history
Dispatcher and manager roles, conflict warnings, a change history on each job, and an import from the old spreadsheet ship in weekly releases.
Weeks 9 to 12
Run in parallel, then switch
The team uses both for two weeks. Gaps they find become requests, and the spreadsheet is archived read-only at cutover.
Where it ends up
Scheduling happens in one tool with roles and a record of every change, the spreadsheet is retired, and the next requests in the queue are the reports finance asked for during the parallel run.
Technologies we use
A short, well-known list. We'd rather know a few tools deeply than list every framework we've touched.
| Area | Tools |
|---|---|
| Front end | Next.js, React, TypeScript, Tailwind CSS |
| Back end | Node.js, PostgreSQL, Prisma, Redis, GraphQL |
| Services | Stripe, Auth0 and Clerk, Resend, Sanity and Contentful |
| Hosting | AWS, Papel Cloud, Vercel |
Which development plan fits
Web applications is delivered under a development subscription. These are the plans that suit this work best.
Starter
$390 per month, best fit
One web app with one request in progress at a time. A good fit for a first version or a steady backlog.
Start with StarterGrowth
$790 per month
Two requests in parallel and a dedicated designer, for teams shipping web and mobile together.
Start with GrowthScale
$1,490 per month
Four parallel requests and an uptime SLA on hosted apps, for products that carry revenue.
Start with Scale
Common questions
If yours isn't here, ask us on a call or by email.
Can you work on an existing codebase?
Yes. We start with a short code review, flag anything risky, and then pick up requests in your existing stack. If the stack is outside what we know well, we'll say so before you subscribe.
Who hosts the app?
Your choice. We can deploy to your own AWS account, to Papel Cloud, or to another provider you already use. Either way, you hold the accounts and credentials.
How big can a single request be?
A request is sized to ship within a week or two. Larger features are split into several requests that each deliver something you can use.
Do you write automated tests?
Yes. New code ships with unit and integration tests, and critical user flows get end-to-end tests that run on every pull request.
Can our in-house developers work in the same codebase?
Yes. We follow the same branch, review and testing rules as your team, and we're happy to review their pull requests or have them review ours.
What happens to the code if we cancel?
Nothing changes for the code: it's already in your repositories with tests and documentation. We hand over anything in progress, and you remove our access.
Talk to an engineer about web applications.
A 30-minute call with an engineer, not a sales script. You'll leave with a scope, a plan recommendation and a start date.