Development services
Web Application Development in Bangladesh
Turn a business workflow into a browser-based application your customers or staff can use. Plan the user roles, records and decisions first, then agree the interface, backend and support scope with Okriya.
Discuss a web application projectWhen a web application fits the work
A public website introduces your business. A web application lets someone complete a task with their own records, permissions and progress. If customers need to submit requests, or staff need to review and approve them, the application scope needs to describe those actions as well as the pages.
For a business in Bangladesh, the brief might include Bangla and English content, local date and currency formats, or access from phones on variable connections. Include these requirements when they affect your users. A browser-based application can be a useful starting point when installation and app-store distribution are unnecessary.
Customer and partner portals
Define account access, submissions, document uploads, status tracking and the information each customer or partner may see. Agree notification and support responsibilities.
Staff workspaces
Map an internal workflow such as requests, approvals, scheduling or reporting. Specify who creates a record, who changes it and which actions need a history.
For a content-led company website, start with our website development service. For a store, review ecommerce development.
Agree the workflow before the screens
- People and permissions: list customers, operators, managers and administrators. Describe the records and actions each role can access.
- Records and states: identify the main records, required fields and allowed changes. A request might move from draft to submitted, reviewed and completed.
- Exceptions: decide what happens when information is missing, an approval is rejected, a duplicate is submitted or a third-party service is unavailable.
- Reporting: name the questions each report must answer and who can export its data.
- Release boundary: separate essential launch journeys from later enhancements. An agreed first release makes estimates and acceptance more useful.
A useful acceptance example is: “An operator can review an assigned request, but cannot open another team’s documents.” That gives the design and testing work a clear outcome.
Backend, integrations and existing data
The browser interface is one part of the application. Include the database, account access, administration and external systems in the estimate. If an existing service already owns a customer or order record, decide whether the new application reads it, updates it or maintains a separate copy.
For an integration, provide the available documentation, a sample response with sensitive details removed and the access process. Our API development and integration service covers the questions to settle around field mapping, failures and reconciliation.
Migration needs its own scope: source files, record volume, duplicate handling, a trial import, validation and a cutover plan. Confirm which history must remain searchable and which material can be archived. Avoid treating a spreadsheet upload as proof that the migrated workflow is correct.
Review the application before launch
- Complete the agreed journeys using representative records and each user role.
- Check keyboard access, labels, validation, loading states and usable layouts on desktop and mobile.
- Test permission boundaries on the server as well as in the interface.
- Agree which pages are public and searchable, and which account areas should remain private.
- Review the deployment, monitoring, backup and recovery responsibilities included in the scope.
Performance targets should use realistic record counts and the devices and connections your users depend on. Public landing pages and a signed-in reporting screen need different checks; a single homepage score does not describe the whole application.
What to send for a proposal
Share the current workflow, user roles, sample records, current systems, expected usage and the first release you need. Include your target date, budget constraints and the person who can approve process decisions. We can then discuss the build, dependencies and review milestones.
The proposal should identify source-code and deployment access, documentation, training, support hours and responsibility for future changes. Hosting, third-party usage and ongoing maintenance should be visible alongside the development scope.
Do we also need a mobile app?
That depends on installation, distribution and device requirements. Read the web app and progressive web app comparison, or discuss a separate Android and iOS app scope if store distribution or deeper device features are important.