Customer portals
Orders, documents, invoices and status behind one login, with separate roles for your customers' teams and yours.
External users · roles · audit log
[ Applications · Custom ]Web application development services
Custom web applications, shaped by the work they replace.
Customer portals, internal tools, dashboards and SaaS MVPs, scoped from how your team works today. Paid discovery sets the scope, Laravel is the default back end, and you own the code from the first commit.
Discovery2 weeks, fixed price
Build8-20 weeks, planned by release
Back endLaravel by default
Front endChosen per product
DeliveryTests, CI/CD, staging
OwnershipYour repository and cloud account
Discovery 2 weeksCode ownership From commit oneReleases Staging firstFirst reply 1 business dayWritten into every web application proposal
[01]Fit and scope
Do you need a custom web application?
Good fit if
- Your team runs a core process on spreadsheets, email and copy-paste
- Customers or partners need their own login for orders, documents or status
- Two or more systems need to share data without manual re-entry
- You want a first product release in front of paying users
Not a fit if
- A SaaS tool already covers the workflow and its limits are acceptable
- You need a marketing website, not an application
- Nobody on your side can own product decisions during the build
- You want a fixed price before anyone has mapped the workflow
[02]What we build
Six kinds of application, one delivery standard.
Defined by the workflow, not the framework. If a SaaS product already does the job, we will tell you to buy it.
Internal tools
Approvals, scheduling, intake and inventory moved out of shared spreadsheets and into screens with permissions.
Ops · finance · field teams
Dashboards and reporting
The numbers your team copies from three systems each week, pulled automatically, with filters, exports and alerts.
Reports · exports · alerts
SaaS MVPs
The first paid version of a product: sign-up, accounts, billing and the one workflow buyers pay for.
Tenants · billing · onboarding
Integrations
CRM, ERP, payment and shipping systems connected with retries and alerts, so each record moves once.
APIs · webhooks · sync jobs
Rescue and rebuild
An app a previous team left behind, reviewed first, then stabilized, upgraded or rebuilt in stages.
Code review · upgrade path
[03]Discovery first
Two weeks of discovery before any production code.
Discovery is paid, fixed-price and yours to keep. It turns a workflow into a scope, a prototype and an estimate you can take to any team.
Map the work
Interviews with the people who do the job, the data they touch and the systems involved. We watch the current process before we redesign it.
Shape the product
Roles and permissions, the core screens, integration contracts, the release plan and what stays out of release one.
Price it
Written scope by release, timeline, fixed price, a clickable prototype of the core flow and a walkthrough.
After discovery you hold the scope, the prototype and the estimate. Build with us or with anyone.
[04]Scope by area
What a web application build covers here.
Marked included, excluded or optional in every proposal.
Product scope
A release plan with goals and non-goals. Every feature has an owner, acceptance criteria and a reason to be in release one.
UX for roles and states
Screens designed per role, with empty, loading, error and no-access states drawn before they are built.
Stack choice
Laravel back end by default. Livewire, Inertia or Next.js on the front, picked for the product, with the reason written down.
Data and integrations
Data model, imports from the old system and typed contracts for every external API, with retries and alerts.
Testing
Automated tests on business rules and permissions. Every pull request runs the suite before it can merge.
CI/CD and environments
Staging and production, deploys from the pipeline, and database migrations rehearsed on staging first.
Security and access
Two-factor sign-in where it matters, rate limits, dependency scanning and an audit log of sensitive actions.
Hosting and handoff
Hosted in your cloud account. Repository, runbooks, architecture note and a recorded walkthrough for your next developer.
[05]Inspectable artifact
A release-one scope sheet, as we write it.
A sample with illustrative values, not a client result. Every line has a role, a release decision and a reason.
| ID | Feature | Roles | Release | Reason |
|---|---|---|---|---|
| F-01 | Client sign-in with two-factor | Client · staff | R1 · included | Every other screen depends on it |
| F-04 | Document upload with status | Client · reviewer | R1 · included | Replaces the shared inbox |
| F-07 | Approval queue with audit log | Reviewer · manager | R1 · included | The core workflow |
| F-11 | One-way CRM sync | System | R1 · included | Ends manual re-entry |
| F-15 | Two-way CRM sync | System | R2 · deferred | Conflict rules need real usage first |
| F-19 | Native mobile app | Client | Excluded | Responsive web covers release one |
[06]Engagement models
Discovery, then a build sized to the first release.
What changes the price: number of roles, integrations, data migration, real-time features and compliance needs.
Scope A · Internal tool or dashboard
One team, one workflow
8-12weeks
- Discovery sprint
- Up to 3 roles, 1-2 integrations
- Tests, CI/CD and staging
- Runbooks and handoff
Scope B · Customer portal
Give customers their own login
12-16weeks
- Discovery sprint
- UX design with clickable prototype
- External and internal roles
- 3-5 integrations, audit log
- Monitoring and support handoff
Scope C · SaaS MVP
Ship the first paid version
14-20+weeks
- Discovery sprint
- Accounts, teams and billing
- Core workflow plus onboarding
- Usage events for product decisions
- Plan for version two
[07]Concept
An intake portal that ends the email chase.
A concept for a professional-services firm: client documents arrive through a portal with checklists and reminders, not email attachments. Staff work from one queue with status and an audit trail.
See concept work[08]Adjacent
Bigger, smaller or different?
Three doors next to this one.
S11
Laravel Development Services
Customer portals and internal tools with roles, integrations and a rollback plan that has been tested.
S03SaaS Product Design
Onboarding, roles, empty states and the screens that drive activation.
S02UX Audit of your app
Expert review, analytics and Core Web Vitals check, severity-ranked backlog.
[09]Questions
Web application questions.
How is this different from your Laravel development service?
This service starts from the workflow and the business problem, and the stack is chosen in discovery. Laravel development is for teams that have already picked Laravel or run a Laravel app that needs specialists. Both use the same delivery standard.
Why is Laravel the default back end?
It gives us mature queues, testing, authentication and deployment tooling, plus a large hiring pool for whoever maintains the app later. If your team already runs Node, .NET or Django, we discuss it in discovery. If another team fits better, we say so.
Should we build or buy?
Buy when a SaaS product covers the workflow and its limits are acceptable. Build when the workflow is how you compete, when tools force double entry, or when per-seat fees grow faster than the team. Discovery ends with that recommendation in writing.
Why is discovery paid?
It produces assets you keep: a scope, a clickable prototype, an architecture note and a fixed estimate. If you build with another team, all of it goes with you.
How do you estimate a build?
Per release, from the scope sheet. Each feature has acceptance criteria, so the estimate covers known work. New ideas go through a written change request with time and cost before anyone builds them.
Do you design the interface too?
Yes. Our UX team designs the core flows for each role, including empty, error and no-access states. Where we can, we test the prototype with real users. Deeper research or a full design system is scoped as SaaS product design.
How do you test and release?
Automated tests run on every pull request, and a failing suite blocks the merge. Releases go to staging for your review, then to production through the pipeline. Each release has a written rollback step.
Where is the app hosted, and who owns it?
It is hosted in your cloud account, and the repository lives in your GitHub organization from the first commit. You hold the admin credentials. We work as invited users you can remove.
Can you take over an app another team built?
Yes, after a paid review of the code, dependencies, tests and deployment. You get a written report with risks and options: stabilize, upgrade in stages or rebuild parts. We do not promise a fix before we have read the code.
What happens after launch?
Most apps need updates, monitoring and small changes after launch. A care plan covers that with named response windows. If your developers take over instead, they get the runbooks and a recorded walkthrough.
[10]Next step
Tell us the workflow. We'll tell you whether to build it.
- 01 · TodayInstant confirmation and a booking link.
- 02 · 1 business dayA senior engineer replies personally.
- 03 · 5 business daysA discovery proposal, or advice to buy instead.