A custom web application project moves from understanding the business workflow to agreeing on scope, designing the interface, building, testing, and launching. Clients review the work along the way, then test the completed application before it goes live.
At retroXpect, we keep this practical. Smaller projects need fewer planning steps; larger systems need more detail and review.
1. Understand the workflow
We start with a call to understand how the business currently works. Spreadsheets, forms, and screenshots help show what staff do and where problems occur.
A request such as “we need an admin panel” needs more explanation: which information should appear, where it comes from, and what users do with it. Those answers become software requirements.
We record the workflow and send the client a message confirming our understanding. The client checks it before we prepare the proposal.
2. Agree on the scope
Once the workflow is confirmed, we send a quotation and project scope agreement for review and signature.
The scope describes the functionality being built, relevant user roles, integrations, and important exclusions. Check it against your daily operations and involve anyone who needs to approve the system internally.
For budgeting, see our web application development cost guide for Singapore.
3. Review wireframes and design
We normally prepare wireframes so clients can visualise the screens and how users move through the application. We may skip them when the scope is especially straightforward.
Review whether staff can find the information and actions they need. It is easier to adjust a flow here than after it has been built. Visual design then develops the agreed layout.
4. Plan the technical setup
The developers decide how the interface, application logic, and stored data will work together. They also plan account access, external integrations, and deployment.
Clients should confirm which existing systems need to remain connected and help arrange the necessary access. The technical planning should fit the project, without turning a small tool into an elaborate architecture exercise.
5. Build and preview the application
Our developers and engineers work directly with the client in a WhatsApp chat. We share a staging link for live preview and update it as development progresses, so clients can preview and test available functionality.
Clients can discuss requirements directly with the people implementing them. Demo calls can also be held at milestones if requested.
When giving feedback, identify the screen, what you tried, and what happened. The team should make clear which parts are ready to test and which are still being built.
6. Test in staging
Staging is a separate environment for previewing and testing changes before they reach live users.
For existing applications, we request staging access where possible. If none exists, we may create a copy of production. We inspect the application and back up systems before work.
Test data and external connections need checking so this ensrues preview activity does not affect live records or customers.
Our internal testing checks the agreed workflows, account permissions, and integrations, including what happens when an action fails. For existing systems, this also includes checking affected functionality still works.
7. Complete user acceptance testing
User acceptance testing, or UAT, is different from QA testing. QA testing can be done by the developers and clients using test accounts, to make sure the web app works as intended. UAT tests with real users, in realistic scenarios, before the web app goes live.
End users should complete their normal tasks from beginning to end and check the resulting records or output. Watching a demo alone will not reveal everything they might encounter in daily use.
Report issues with the steps taken, expected result, actual result, and a screenshot where useful. Agree who will collect feedback and confirm the application is ready to launch.
8. Review changes
Some feedback identifies a bug; other feedback clarifies a requirement or introduces additional functionality. Compare the request with the agreed scope before deciding how to handle it.
If extra work affects the estimate or launch date, agree on that before it begins. Our article on why small web app features can be expensive to build explains the development impact in more detail.
9. Launch and hand over
Before deployment, resolve significant testing issues and check production settings, database readiness, and external connections. For an existing system, take an appropriate backup and agree on the changeover timing.
After launch, check key functions in the live environment. Production settings can differ from staging.
Confirm who controls the application accounts, where the source code is held, and how early issues will be reported. The support period should follow the project agreement. Our web app maintenance cost guide covers longer-term support.
What can delay a project?
Unclear workflows, missing access, changing requirements, and late testing feedback can hold up progress. Agree who makes decisions and allow time for client testing. The development team should flag any potential blockers early and explain what is needed to continue.
What to prepare for the first call
Bring:
- Your current workflow and main problems.
- Who uses the process and what each person does.
- Existing spreadsheets, forms, screenshots, and sample outputs.
- Systems that need to connect to the application.
- The person responsible for reviewing and approving the work.
You do not need a technical specification. Use sample or redacted data when sharing examples.
Frequently asked questions
How long does web application development take?
Allow roughly 6–12 weeks for a focused custom web application as an initial planning range, including design, development, testing, and review. Small tools can take less time; larger systems can take months. Confirm the schedule with the developer once the scope and dependencies are understood.
Do I need complete requirements before contacting a developer?
No. Explain your current workflow and the problem you want to solve. A good web development agency can help turn that into requirements for you to review.
Can requirements change during development?
Yes. Discuss whether the change clarifies the agreed scope or adds functionality, then confirm any effect on the estimate and timeline.
Who owns the source code after launch?
Check the project agreement before signing. It should explain ownership, access, and handover expectations, including third-party components. If not, clarify with the web development agency to prevent and conflicts after launch.
What happens after launch?
Users begin working with the application, and early issues go through the agreed support arrangement. Maintenance and further development should have a defined scope. All of our work at retroXpect comes with a minimum of free 14 days maintenance post-launch.
Planning a web application? Start with the workflow
Show us how your process works today, whether it runs through spreadsheets, manual handoffs, or an existing system. retroXpect can help turn it into a practical development scope.
