Customer & Household Digital Applications
Applications used directly by the people they are built for — customers, individuals and households — rather than by an internal team. The audience has no training, no manual and no patience, which changes almost every design decision.
The situation this service is built for
Two quite different starting points lead here. The first is a business whose customers currently telephone or email for things they could do themselves — checking a booking, updating details, submitting a request, seeing what has happened to an order. Every one of those contacts costs staff time and delivers no additional value.
The second is an idea for an application that individuals or households would use directly: organising a shared home, tracking recurring commitments, coordinating schedules between people, or managing a personal set of records. Here there is no existing process to model — the design has to establish one.
In both cases the defining constraint is the same. Nobody using the application has been trained, nobody will read instructions, and anyone who becomes confused simply leaves. Clarity is therefore not a finishing touch; it is the specification.
The exact application is designed around the agreed use case. Nothing on this page describes a product that already exists and is waiting to be configured.
Problems this service may address
- Routine requests consume staff timeQuestions that a customer could answer themselves arrive by telephone and email throughout the working day.
- Bookings are managed manuallyAppointments are arranged through back-and-forth messages, with double-bookings and missed slots as a predictable result.
- Customers cannot see their own informationDetails held about a person are invisible to them, so corrections depend on somebody being asked.
- Onboarding is inconsistentNew customers experience a different first week depending on who handled them and how busy that person was.
- Household coordination lives in messagesShared commitments, schedules and responsibilities are spread across chat threads with no single view.
- A good idea has no shape yetThe concept is clear but the screens, the sequence and the smallest useful first version have not been defined.
What an application can contain
These are possible directions within this service, not a checklist that every project receives. The proposal names the specific features included.
Possible examples
- Customer self-service tools
- Booking and appointment applications
- Household organisation portals
- Personal scheduling systems
- Membership or account areas
- Simple home-management tools
- Customer onboarding applications
- Responsive browser-based utilities
Typically included in scope
- Use-case definitionWho the user is, what they arrive to do, and what success looks like in a single session.
- Journey and screen designThe sequence of screens and the state of each one, designed for an untrained user.
- Account handling where requiredRegistration, sign-in and password recovery using established, well-tested patterns.
- Responsive build and testingDevelopment and testing across phone, tablet and desktop widths.
- Accessibility fundamentalsKeyboard operation, labelled controls, sensible contrast and clear error messages.
- Deployment and handoverRelease to the agreed environment with documentation for whoever administers it.
What is not automatically included
- Native mobile applications and store publicationApplications are delivered as responsive web software. Publication to the Apple App Store or Google Play is not included unless it forms part of the agreed project.
- Physical hardware of any kindDEVNOVA does not design, manufacture or supply smart-home devices, sensors or any other physical product.
- Payment processingWhere payments are required, a third-party provider is integrated. Provider selection, account approval, fees and compliance obligations rest with the client.
- Marketing, content and photographyCopywriting, imagery and campaign material are the client's responsibility unless separately agreed.
- User acquisitionBuilding an application is not the same as attracting people to it. Growth is outside the scope of this service.
- Ongoing moderation or customer supportWhere an application involves user-generated content or account queries, the operational response remains with the client.
Engagement process
Use-case definition
A short, precise statement of who the application is for and the single task it must make easy. Applications that try to serve four audiences at launch tend to serve none of them well.
Journey mapping and scope
The screens, their sequence and the decisions available at each point are mapped out. The written proposal follows, listing features, exclusions, price and indicative timescale.
Interface design
Layouts are produced for the agreed screens, including their empty, loading and error states — the states that determine whether an unfamiliar user continues or abandons.
Build and cross-device testing
Development with continuous testing across screen widths and current major browsers, including keyboard operation and input validation behaviour.
Review with real users where possible
A review period in which people outside the project — ideally representative of the intended audience — attempt the main task without guidance. Where they hesitate is more informative than any opinion in the room.
Launch and handover
Deployment to the agreed environment, administrative documentation and a walkthrough of how to manage accounts and content after launch.
Expected deliverables
- The working applicationDeployed to the agreed environment and tested across the agreed range of devices.
- Source code for the custom workDelivered in a repository, with ownership addressed in the written agreement.
- Screen and journey documentationThe agreed sequence, including the error and empty states that are easy to forget later.
- Administrative documentationHow to manage accounts, adjust content and carry out routine tasks.
- Accessibility notesWhat was checked, what was addressed, and any known limitations stated honestly.
- Acceptance recordThe agreed criteria with test outcomes, forming the basis of project completion.
Client responsibilities
- A clear decision on the primary audience, and a willingness to keep it narrow at launch
- Content: text, terms, pricing information and any imagery the application displays
- Accounts with any third-party provider the application depends on, such as payment or messaging services
- Access to a few representative users for the review stage, where that is possible
- Timely feedback at review points, within the agreed window
- Responsibility for the application's own legal requirements — terms of use, privacy information and any sector rules
Factors that affect scope and price
Increase scope
- User accounts with roles, sharing or household-level permissions
- Payment handling, subscriptions or refund logic
- Notifications by email or message, particularly with scheduling rules
- Calendar synchronisation with external providers
- Several distinct user types with different journeys
- Bespoke visual design rather than a clean functional interface
Keep scope lean
- One primary task, done exceptionally well
- A single user type at launch
- Email notification only, without scheduling complexity
- Content supplied ready to use, in final form
- Accepting a first version and extending it once real usage is visible
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
After launch
Customer-facing applications generate feedback immediately, which is exactly why the first version should be modest.
Settling period
A defined period after launch during which defects against the agreed specification are corrected at no additional charge.
Refinement round
A short scoped piece of work responding to what early users actually struggled with, rather than what was predicted.
Feature extension
A second phase adding the capabilities deliberately deferred, once demand for them has been demonstrated.
Questions about this service
No. This service delivers software used by individuals and households — organisation tools, scheduling, shared records and similar applications running in a browser.
DEVNOVA does not design, manufacture or supply physical hardware of any kind, including sensors, controllers or smart-home devices. Where an existing device provider offers a documented interface, connecting to it may be possible, but that is an integration question rather than hardware production.
Not by default. Applications are delivered as responsive browser-based software, which works on phones without installation and avoids store review cycles entirely.
Where store publication is genuinely required, it is discussed during scoping and priced as part of the project. It brings additional obligations — developer accounts, review processes and ongoing platform requirements — which are set out before anything is agreed.
Payments are handled by integrating an established third-party payment provider, so card details are processed by that provider rather than stored in the application.
The client holds the merchant account, accepts the provider's terms and fees, and remains responsible for any regulatory obligations attached to taking payments. Integration work is scoped and priced separately from the core application.
The starting position is to collect as little as the application genuinely needs. Fields that exist only because they might be useful later are challenged during scoping.
Access controls, sensible storage practice and export or deletion routes are built in where relevant. That is sound engineering, not a compliance guarantee: responsibility for the application's data protection obligations rests with the client, who should take their own professional advice where the data is sensitive.
No — that is the normal starting point for this service, and use-case definition is the first stage precisely because of it.
Where the concept is still contested internally or a budget must be justified before commitment, a short feasibility engagement first is often the cheaper route.
Continue
Services that often accompany this one
Service enquiry
Who is it for, and what should it make easy?
Two sentences answering those questions are enough to begin. The enquiry form will arrive with this service already selected.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom