Show the right information
Give different users the screens and information they need for their role. Agree who can see or change each record and what happens when access is unavailable.
Web app development for your client projects.
Your client needs more than a website to read. They need people to sign in, find information and carry out a particular task. Odd Little Bits can build the browser-based application behind those interactions, working with your agency on the scope, development and review.
We work fully online and in writing. Your agency can stay close to the client and bring together their feedback; we agree what the application needs to do and how it will be handed over.
Get in touchWhat could the application do?
These are possible parts of a project, not a fixed feature package. An application can also connect to existing tools; our integration work explains the decisions behind those connections. For operational steps such as ownership and approval, see workflow software.
Does this need a custom application?
Sometimes an existing product, a content management system or a clearer process already does what the client needs. Start with the task and the constraints before deciding to build.
Custom development may be useful when the required screens, actions or connections do not fit the available tools. The decision depends on the project, including who will use it, what needs to be maintained and what the existing systems allow.
Agree what the first release needs
A useful starting point is the main task a person should be able to complete, rather than a list of every feature the application might eventually have. Together we can define the first release and identify the decisions still open.
- Who will use the application, and what should each role be allowed to see or do?
- Which records and screens are needed for the main task? Who owns the information?
- Which existing tools need to connect, and what access or interfaces are available?
- Which designs and content will your agency supply, and who approves them?
- What should work at review, what is excluded, and how will the agreed behaviour be checked?
You do not need to provide a technical architecture. The development brief for agency projects can help bring the wider requirements together.
A fictional application example
This example is invented to show the decisions involved; it is not a client project or a standard package.
An agency’s client wants a browser portal where customers can sign in, see their own project information and submit a request to change a detail. The client team can review each request alongside the relevant record.
The scope would need to say which project information a customer can see and check that one customer cannot open another customer’s record. If the project information is not available, the screen should explain that it could not be loaded instead of showing a blank page. If a request cannot be submitted, the customer should know it has not been sent and what to do next.
Before the build, agree where the information comes from, who can review a request and which actions are included in the first release. Those details shape what can be tested at review.
Build, review and handover
We agree the work in writing and share progress for review. Your agency can check the application against the agreed user actions and bring together client feedback. If a request changes the scope, we discuss its effect on the work before adding it.
Handover includes the source and setup notes, with access arrangements and known follow-up decisions made clear. Ongoing support or maintenance can be scoped separately. Read more about how the project process works and the white-label working arrangement.
Have an application in mind?
Tell us what users need to achieve, what already exists, which designs are ready, any tools the application needs to connect to and any relevant deadline. There is no need to send passwords, access tokens or real customer records in the initial enquiry.
Get in touchOpens the contact form on Tally in a new tab.