• Working worldwide
  • 14 years of development experience
info@deviec.com
DEVIEC
Start your project

Service

Web applications your business runs on

Software that lives in a browser and has users, permissions, records and rules. We design the data model and the access model first, then build it in Laravel or PHP so it can be extended for years rather than replaced in two.

  • Portals, dashboards, SaaS platforms and internal tools
  • Roles and permissions designed before any screen is built
  • Delivered in working increments you can use as they land
  • Built to be handed to another developer without a rewrite
Discuss your applicationAll services
A business analytics dashboard displayed on a widescreen monitor

What counts as a web application?

Anything where a user signs in and the software does work for them: a portal a client logs into, a dashboard your team runs the operation from, a subscription platform you sell access to, or an internal tool that replaces a spreadsheet three people maintain by hand. The distinguishing feature is state — records that change, permissions that govern who may change them, and rules that must hold every time. A website presents information; a web application does something with it.

  • Users sign in, and what they can see and do depends on who they are
  • Records move through states, and the history of that matters
  • Rules and calculations must produce the same answer every time

What we build

The applications we are asked for most

Different products, one underlying shape: authenticated users acting on shared data under rules.

  • Client portals

    A signed-in area where customers see their own jobs, documents, invoices or reports without emailing to ask.

    • Per-account data isolation
    • Document handling
    • Notification rules

  • Operational dashboards

    One screen showing the true state of the business, replacing a spreadsheet several people update and disagree about.

    • Live operational data
    • Filtering and export
    • Audit trail

  • SaaS platforms

    Software you sell access to, with plans, billing, onboarding and the tenant separation that has to be right from day one.

    • Multi-tenant architecture
    • Subscription billing
    • Self-serve onboarding

  • Internal tools

    The unglamorous applications that remove hours of manual work each week and never appear in a marketing brochure.

    • Bulk operations
    • Approval steps
    • Role-based access

  • Booking and scheduling

    Availability, capacity and the awkward exceptions your business actually has, rather than the ones a generic product assumes.

    • Availability logic
    • Capacity rules
    • Confirmation workflow

  • APIs and integrations

    A documented interface so your application can be consumed by another system, or can consume one reliably.

    • REST API design
    • Versioning
    • Retry and failure handling

Where applications go wrong

The failures we are usually called in to repair

Almost none of these are coding mistakes. They are decisions taken early, cheaply, and never revisited.

  • Permissions bolted on afterwards

    Access control added once the screens existed, so it is enforced in the interface rather than in the data layer and can be bypassed by anyone who guesses a URL.

  • A data model that cannot bend

    Tables designed around the first customer's process. The second customer needs one extra field, and it becomes a column nobody dares remove.

  • Tenant data sharing a table with no guard

    Multi-tenant separation enforced by remembering to add a WHERE clause. It works until the one query where somebody forgets.

  • Reports that lock the database

    Analytics run against the live transactional tables, so generating the monthly report slows the application for everyone using it.

  • No audit trail

    A record changed, nobody knows who changed it or what it said before, and the dispute cannot be resolved.

  • Deploying by copying files

    No staging, no migrations, no rollback. Every release is done carefully by hand and one of them will eventually go wrong.

How we start

The data model and the permission model come first

Screens are the easiest part of an application to change and the hardest part to resist starting with. Underneath them sit two decisions that are expensive to reverse: what the records are and how they relate, and who is allowed to do what to them.

So we settle both before building interfaces. What entities exist, what each one owns, which relationships are one-to-many and which are genuinely many-to-many, what has to be soft-deleted for audit, and where tenant boundaries fall. Then the permission model: roles, the actions each role may take, and enforcement in the data layer rather than in the template. Get those right and new features are additive. Get them wrong and every feature fights the foundation.

  • Entities, relationships and ownership mapped before any screen
  • Permissions enforced in the data layer, not in the interface
  • Tenant isolation designed in rather than remembered per query
  • Audit trail on the records where history will be disputed
See how we scope work
A person using a web application on a laptop

Scope

What a web application engagement covers

Foundations

  • Data model and entity relationships
  • Authentication and session handling
  • Roles, permissions and tenant isolation
  • Environment separation and configuration

The application

  • Screens built around the tasks users actually perform
  • Server-side validation on every input
  • Background processing for anything slow
  • Search, filtering and export where the data warrants it

Interface quality

  • Responsive from 320 pixels up, tested at real widths
  • Keyboard operable with visible focus throughout
  • Accessible forms with clear error identification
  • Tables that stay usable on a narrow screen

Data and reporting

  • Reporting that does not contend with live transactions
  • Export in formats your team already uses
  • Import and bulk update routines
  • Retention and archiving where records accumulate

Operations

  • Database migrations under version control
  • Deployment process with a rollback path
  • Error logging and alerting
  • Backups with a restore tested before launch

Handover

  • Repository and documentation transferred to you
  • Written architecture and data-model notes
  • Runbook for deployment and common operations
  • An agreed support arrangement, or a clean exit

Delivery

How an application build runs

Applications are delivered in working increments rather than revealed at the end, because the requirement always changes once people can click on something real.

  1. 01

    Discovery

    Users, roles, processes, rules, data and integrations. Charged as its own fixed-price stage, because an estimate before this is a guess.

    You receive: Written specification and estimate

  2. 02

    Architecture

    Data model, permission model, integration approach, environments and the release process.

    You receive: Technical design you own

  3. 03

    First increment

    The smallest slice that is genuinely usable, so the shape of the thing can be judged early rather than assumed.

    You receive: A working application you can log into

  4. 04

    Build out

    Further increments in priority order, each reviewable on staging, each with the change process applied to anything new.

    You receive: Reviewable releases

  5. 05

    Test and migrate

    Functional testing against the specification, permission and failure-path checks, then data migration and user setup.

    You receive: Test record and migrated data

  6. 06

    Launch and support

    Planned cutover with a rollback path, training, then a defined support and release arrangement.

    You receive: Live application and support agreement

Stack

What we build web applications with

Chosen for maintainability and for the fact that another developer can pick the codebase up.

Application

  • PHP
  • Laravel
  • CodeIgniter
  • Queues and scheduled jobs
  • Authentication and roles
  • Automated tests on business rules

Data

  • MySQL
  • MariaDB
  • Schema migrations
  • Query profiling
  • Redis caching
  • Import and export routines

Interface

  • Server-rendered views
  • Tailwind CSS
  • Vanilla JavaScript
  • Accessible forms
  • Responsive data tables

Integration

  • REST APIs
  • Webhooks
  • Payment and billing providers
  • Email and notification services
  • Third-party SDKs

Operations

  • Git-based deployment
  • Staging environments
  • Error logging and alerting
  • Uptime monitoring
  • Backup and restore

Security

  • Parameterised queries
  • Output escaping
  • CSRF protection
  • Rate limiting
  • Least-privilege access
  • Secrets outside the repository

Questions

Web application questions

How is this different from your custom web development service?
They overlap and the boundary is soft. Custom web development is the wider engagement, including the question of whether bespoke software is the right answer at all and what should be integrated rather than built. This page is about the thing itself once that decision is made: a browser-based application with users, permissions and state. If you are not sure which you need, start a conversation and we will tell you.
Do you build mobile apps?
No. We build web applications, which run in a browser on any device and which we make properly responsive so they work on a phone. Native iOS and Android development is not a service we offer, and we would rather say so than take the work and subcontract it without telling you.
Can you take over an application somebody else built?
Usually, after a paid assessment of the code, data model and hosting. You get a written view of what it does, what is risky and what it would take to make it maintainable. Occasionally the honest finding is that it should be replaced rather than extended, and if so we will show you the arithmetic rather than just asserting it.
How long does an application take to build?
It depends almost entirely on the number of distinct rules and integrations, which is what discovery establishes. What we can commit to is that you will have something working to log into early rather than at the end, so the timeline is visible as it progresses instead of being a single date you have to trust.
Who owns the code and the data?
You do. The repository, the documentation and the database are yours, and hosting stays in your name. Custom code transfers to you on final payment. We do not build a dependency on infrastructure only we control.
What happens after launch?
Applications need a named owner, because unlike a brochure site they keep accumulating data and dependencies. That can be us under a support arrangement covering monitoring, releases and an allocation of development time, or your own team with a proper handover. Both are genuine options.

Related services

Often paired with this

Have an application to build?

Describe who would use it, what process it replaces and what goes wrong today. We will tell you whether it needs building and what we would do first.

Discuss your applicationSee our process