Build
Create the workflow, interface, and data model when they are central to how the business operates or differentiates itself.
Software shaped around the way your business actually runs.
Replace disconnected spreadsheets, duplicate entry, and fragile handoffs with a focused application built around the operation your team performs every day. PlinthWeb designs secure, accessible systems in useful phases—with roles, integrations, migration, and ownership planned from the start.
Estimate
Harbor & Main
Estimate ready for approval
- Owner
- Maya Chen
- Next action
- Send revised scope
Open record
Activity history, attachments, approvals, and the next accountable step stay with this record.
01Workflow and data model shaped around the real operation
02Role-based interfaces for staff, managers, customers, or partners
03Integrations, migration, reporting, and exception handling planned
04Phased delivery with security, accessibility, and ownership defined
Application blueprints
Build the operating tool the business is missing.
A custom application can focus on one painful workflow or connect several related operations. The right first release is the smallest complete system that creates reliable value without pretending every future feature belongs in version one.
Application blueprint01 / 09
CRM and sales pipeline
Centralize companies, contacts, leads, opportunities, activities, follow-ups, ownership, and the context a team needs to move a relationship forward.
Primary workflow
- Account and contact histories
- Lead qualification and opportunity stages
- Tasks, reminders, notes, and handoff rules
Application blueprint02 / 09
Customer and partner portals
Give external users an authenticated place to submit information, see appropriate records, exchange files, approve work, and follow status without exposing internal tools.
Primary workflow
- Client onboarding and profile updates
- Request, project, or order status
- Secure document and message exchange
Application blueprint03 / 09
Scheduling and dispatch
Coordinate appointments, staff or field resources, availability, service locations, work requirements, assignment, and status through one operational view.
Primary workflow
- Calendar and availability rules
- Technician or crew assignment
- Appointment reminders and live status
Application blueprint04 / 09
Estimating and invoicing workflows
Move approved scope and pricing through estimates, revisions, acceptance, deposits, invoices, and accounting handoffs with the business rules made explicit.
Primary workflow
- Estimate builders and approval status
- Digital acceptance and document generation
- Invoice or payment-platform integrations
Application blueprint05 / 09
Inventory and work orders
Connect requested work with parts, equipment, locations, assignments, checklists, completion evidence, and the exceptions that require office attention.
Primary workflow
- Work-order lifecycle and checklists
- Stock, equipment, and location records
- Usage, reorder, and exception signals
Application blueprint06 / 09
Dashboards and operational reporting
Turn trusted business records into role-appropriate queues, summaries, trends, and exports so people can answer operational questions without rebuilding a spreadsheet.
Primary workflow
- Role-specific work queues and alerts
- Operational and management dashboards
- Scheduled reports and governed exports
Application blueprint07 / 09
Integrations and data synchronization
Connect the application with supported accounting, calendar, email, payment, storage, messaging, or industry systems while preserving a clear source of truth.
Primary workflow
- API and webhook connections
- Import, export, and reconciliation tools
- Failure alerts and safe retry paths
Application blueprint08 / 09
Approvals and document workflows
Route requests, documents, exceptions, expenses, changes, or sign-offs to the right people with status, comments, conditions, history, and reminders.
Primary workflow
- Sequential or conditional approvals
- Document templates and version context
- Decision history and escalation rules
Application blueprint09 / 09
Field and mobile tools
Give teams a focused interface for the information and actions they need away from a desk, designed around device constraints and real working conditions.
Primary workflow
- Mobile job details and checklists
- Photos, signatures, notes, and completion proof
- Location-aware or offline-tolerant flows when scoped
Build, integrate, or automate
Build only what deserves to be custom.
A custom application is appropriate when the workflow creates meaningful differentiation, several tools produce costly gaps, required roles or rules do not fit available products, or a focused system can remove a recurring operational constraint. Discovery examines the process, users, records, decisions, exceptions, security needs, integrations, and cost of the current workaround.
Custom is not automatically the best answer. If a maintained product already fits the important requirements at a reasonable total cost, configuring or integrating it may be safer than creating another system to own. The recommendation separates must-haves, useful later capabilities, and requests that do not justify their complexity.
Integrate
Keep dependable products in place and connect them when the missing value is continuity, visibility, or a reliable handoff.
Automate
Remove repeatable manual steps when the underlying process is already clear and people still retain the right review points.
Operational architecture
A useful application is more than its screens.
01
Model the real operation
Design around roles, state changes, and imperfect handoffs.
The system model identifies who can create, view, change, approve, export, or delete each kind of record; how work moves from one state to another; and which exceptions require intervention. Staff, managers, customers, vendors, and field teams can receive different interfaces rather than navigating one overloaded dashboard.
Integrations are treated as operating dependencies, not decorative logos. Supported APIs, webhooks, imports, exports, authentication, rate limits, duplicate rules, source-of-truth decisions, and outage behavior are reviewed before implementation. When another service fails, the application should preserve context and expose a recoverable action.
- Role and permission matrix by action and record
- State transitions, approvals, exceptions, and notifications
- API, webhook, import, export, and identity planning
- Source-of-truth, duplicate, outage, and recovery rules
02
Treat information as an operational asset
Create records the team can trust, find, and explain.
The data model defines entities, relationships, required fields, validation, lifecycle, retention, and ownership before screens multiply. Existing spreadsheets or platforms are profiled for incomplete values, inconsistent formats, duplicates, and hidden formulas so migration work is estimated honestly rather than discovered during launch.
Dashboards begin with decisions and questions, then select the smallest reliable measures that answer them. Filters, work queues, alerts, drill-down context, scheduled reports, and exports can serve different roles, while calculation definitions and data freshness remain visible so a polished chart does not overstate weak inputs.
- Entity, relationship, validation, and lifecycle design
- Migration profiling, cleanup, mapping, and reconciliation
- Decision-led dashboards, queues, alerts, and reports
- Visible metric definitions, freshness, and export controls
03
Reduce delivery risk
Release one complete workflow before expanding the platform.
The first phase is a usable vertical slice, not a collection of disconnected screens. A prototype validates language, information density, permissions, and the critical path with representative users. The production release then implements the smallest end-to-end workflow that can be tested against agreed acceptance scenarios and supported in real use.
Later phases use evidence from operation to add roles, reports, integrations, automation, or adjacent workflows. Feature requests are ordered by user value, business impact, risk, dependency, and maintenance cost. Data migration, training, parallel operation, and rollback or recovery are included where the change affects existing business records.
- Prototype of critical roles and journeys
- Smallest complete production workflow first
- Acceptance scenarios and representative-user review
- Migration, training, release, and recovery planning
04
Quality is part of the architecture
Plan security, accessibility, and maintenance before launch.
Security is scoped from the data and risk: authentication, role-based authorization, least privilege, secure secret handling, validation, dependency review, audit context, backups or recovery, and appropriate test depth. Sensitive or regulated information may require specialist legal, compliance, infrastructure, or security work beyond a standard application engagement.
Accessibility is considered in structure, keyboard paths, focus, labels, errors, target sizes, contrast, responsive layouts, and assistive-technology behavior, with any formal conformance target named in the scope. Operational ownership covers hosting, monitoring, incident response, account control, source code, documentation, support boundaries, and a maintained path for future change.
- Authentication, authorization, least privilege, and validation
- Keyboard, focus, errors, contrast, responsive, and assistive QA
- Recovery, monitoring, incident, and dependency planning
- Source, data, account, documentation, and support ownership
Delivery system
Five controlled stages from operating problem to useful software.
Each stage produces something reviewable, keeps important assumptions visible, and reduces the risk of discovering workflow, data, permission, or migration problems only after a large build.- 01
Discover
Map users, workflows, decisions, records, exceptions, integrations, risks, success measures, and the build-versus-buy context.
- 02
Prototype
Test the critical journey, interface language, information density, roles, permissions, and acceptance scenarios before full implementation.
- 03
Build
Implement the smallest complete production workflow with its data model, interfaces, integrations, reporting, and operating controls.
- 04
Validate
Test normal and exceptional paths, access boundaries, data migration, accessibility, performance, recovery, and representative user tasks.
- 05
Launch & improve
Release in a controlled way, verify production behavior, train owners, monitor the system, and prioritize later phases from real evidence.
Role-based accessAccessible interfacesOwned source and dataRecovery-minded operations
Custom business application questions
What kind of custom application can PlinthWeb build?
Projects can include CRM and sales tools, customer or partner portals, scheduling and dispatch, estimates and invoicing workflows, inventory and work orders, dashboards, integrations, approvals, document processes, and field tools. Feasibility and scope follow discovery rather than a blanket promise.
Should we build custom software or buy an existing product?
That depends on workflow fit, integration needs, configuration limits, data ownership, security, team capacity, lifetime cost, and the advantage the process creates. If a maintained product meets the important requirements, PlinthWeb may recommend configuration or integration instead of a custom build.
Can the application connect with our current systems?
Often, when those systems offer suitable APIs, webhooks, exports, or supported connectors. The scope confirms authentication, permissions, data mappings, rate limits, vendor fees, duplicate handling, failure behavior, and which platform remains the source of truth.
How are security and access permissions handled?
The project identifies data sensitivity, user roles, allowed actions, authentication, least-privilege access, validation, audit needs, secrets, recovery, and testing appropriate to the risk. Formal compliance or penetration testing is included only when the written scope names it.
Can you replace our spreadsheets without losing the data?
Migration can be planned, but existing data must first be profiled for structure, duplicates, missing values, formulas, history, and ownership. A controlled import uses mapping, validation, sample runs, reconciliation, and a rollback or preservation plan appropriate to the records involved.
How long does a custom business application take?
Timing depends on workflows, roles, data quality, integrations, security, migration, feedback, and release constraints. PlinthWeb defines milestones after discovery and favors a useful first phase that can be validated before committing every future capability to one launch.
Start with the operating problem