Northbound Freight
A shipment portal built over an existing transport management system, so customers can answer their own status questions.
Self-service replaces status calls
03 · Build
Web application development
When a business process outgrows spreadsheets and email, the cost is not obvious at first. It shows up as duplicated data entry, work that only one person knows how to do, and decisions delayed while someone assembles a report by hand.
We build web applications that replace those processes: customer portals, operational dashboards, internal tools and SaaS products – designed around the workflow as it actually runs, not as the org chart describes it.
Signals that a process needs an application
- The same data is typed into more than one system.
- A critical process depends on one spreadsheet and one person.
- Customers ask your team for status updates that they could read themselves.
- Reporting takes days because the numbers have to be assembled manually.
- An off-the-shelf tool covers most of the process, and the remainder is handled by side agreements.
- The current internal tool works but nobody will touch the code.
What we build
Customer and partner portals
Self-service access to orders, documents, status, invoices, support and account data. Reduces inbound support volume and gives customers a reason to stay logged into your business rather than emailing it.
Operational dashboards
Live views of the numbers a team actually acts on, sourced from the systems that hold them, designed so the important state is visible without configuration.
Internal tools and management systems
Applications for a specific operational workflow – scheduling, approvals, resource planning, quality control, inventory, case management – built to fit the process rather than requiring the process to fit the tool.
Booking and scheduling systems
Availability, capacity rules, calendar and resource management, notifications, rescheduling and cancellation policies, payment where relevant.
SaaS platforms and MVPs
Multi-tenant products with user and organisation management, roles and permissions, subscription and billing integration, and an admin surface. Scoped to reach real users quickly without foreclosing what comes next.
Diagram
How we build applications
-
Start from the workflow, not the screens We map how the work actually happens – including the exceptions and workarounds, which are where the real requirements hide – before designing anything.
-
Get permissions right early Roles, permissions and data visibility are foundational. Retrofitting an authorisation model into a working application is one of the most expensive changes there is.
-
Design the empty and the overloaded states Applications are used on day one with no data and in year three with far too much. Both are designed. Most tools are only designed for the demo in between.
-
Build for auditability Who changed what, when, and what it was before. This is nearly free to build in at the start and close to impossible to reconstruct later.
-
Ship in usable increments A working slice of the process in production early, then extension. Long unreleased build phases hide integration problems until they are expensive.
-
Instrument from the first release Error tracking, performance monitoring and usage analytics from day one, so decisions about what to build next come from evidence.
What you receive
- Production application with role-based access control
- Documented data model and API
- Integrations with the systems the process depends on
- Admin interface for the people who operate it
- Automated test coverage on the critical paths
- Deployment pipeline and environment configuration
- Error, performance and uptime monitoring
- Technical documentation and user documentation
- Team training and a defined support arrangement
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Build work sits inside that process rather than alongside it.
Common questions
Should we build or buy?
Buy, if an existing product covers the process without material compromise – we will tell you when that is the case. Build when the process is a genuine differentiator, when integration requirements make off-the-shelf tools awkward, or when licence costs at your user count exceed the cost of owning it.
Can you take over an application someone else built?
Usually. We start with a technical review covering code quality, dependencies, security and test coverage, and give you an honest read on whether continuing, refactoring or rebuilding is the better commercial decision.
What happens after launch?
Applications need ongoing work – dependency updates, security patches, and changes as the process changes. That is a defined support arrangement, agreed before launch rather than negotiated after something breaks.
Related services
Have a process that has outgrown its tools?
Describe how it runs today, including the workarounds. That conversation is usually enough for us to tell you whether it is worth building.
Or email hello@applystudio.com – we reply within one business day.