For custom web application development in Baku, a useful proposal begins before a development company estimates screens, hours, or a fixed price. The buyer needs to define the business problem, the first group of users, the operational workflows, and the boundaries of the first release. Without that context, a quote is usually either padded with risk or too narrow to survive real-world discovery.

If your team relies on spreadsheets, email, messaging apps, and disconnected internal tools to manage customer or operational work, the right answer may be a web application rather than another marketing website. POLADO’s Web Platforms & Applications service helps turn that operational need into a buildable product scope: corporate website, customer portal, internal platform, or a combination of these.

Start by identifying the project type

The phrase “we need a website” can describe three very different products. Establishing which one you need prevents a proposal from comparing unlike work.

  • Corporate website: a public-facing site that explains your company, services, expertise, projects, and contact options. Content management, responsive performance, SEO, analytics, and lead capture are usually the main requirements. It normally has limited account-based activity.
  • Customer portal: a secure area where customers can view documents, submit requests, follow order or case status, download invoices, manage profiles, or contact support. The important question is what a customer can complete without staff intervention.
  • Custom business platform: an internal or multi-party operational system. It may route sales requests, manage approvals, coordinate contracts, process partner activity, track inventory, or consolidate reporting. Its value lies in business rules, role-based access, integrations, and reliable data—not simply in pages or visual design.

A single programme may include all three. A corporate site can generate enquiries, a portal can give customers visibility, and an internal platform can help teams process the work behind those enquiries. A credible proposal should still separate those modules and their dependencies.

1. Define users, roles, and permissions

“Admin and user” is rarely enough for web application project requirements. List each user group and what it is allowed to see, create, edit, approve, export, or delete. For example:

  • A customer sees only records and documents belonging to its own organisation.
  • A sales manager updates assigned leads and prepares offers.
  • A department head approves exceptional discounts or contracts.
  • A finance specialist changes payment status but cannot alter commercial terms.
  • A system administrator manages accounts and roles without making routine business decisions.

This is not merely a UX exercise. A rule such as “customers must never access another customer’s documents” needs enforcement in the application’s authorisation logic and data queries, not only a hidden menu item. OWASP’s Application Security Verification Standard is a practical reference for specifying security requirements and verification expectations for web applications.

2. Describe workflows, not just requested screens

“We need a dashboard” is less useful than explaining how a case moves from creation to completion. For every high-value workflow, document:

  1. What event starts the process?
  2. Who takes the first action?
  3. Which fields are required, and what rules validate them?
  4. What are the statuses, approvals, exceptions, and return paths?
  5. Who receives a notification, through which channel, and at what point?
  6. When is the process completed, cancelled, overdue, or escalated?

For instance, a service-request workflow might be: a customer submits a request in the portal; the system routes it by category; an assigned specialist responds within one business day; if documents are missing, the status changes to “awaiting information”; the final decision is visible to the customer and recorded in an audit trail. That description allows a development partner to estimate real requirements: states, notifications, APIs, reporting, permissions, and exception handling.

If the workflow is still uncertain, begin with UI/UX & Product Design. User journeys, information architecture, and a clickable prototype can resolve expensive assumptions before production development starts.

3. Map integrations and external dependencies

Integrations are often the largest source of estimation risk. “Connect to our ERP,” “show bank payments,” or “sync with 1C” is not yet an implementable requirement. For each external system, provide:

  • the system name, owner, and technical contact;
  • the available connection method: documented API, file export, database access, webhook, or manual upload;
  • the data to be exchanged and its direction;
  • whether the exchange must be real-time, scheduled, or user-triggered;
  • how errors are reported, retried, and reconciled;
  • whether documentation, test credentials, and a sandbox environment are available.

If an API is unavailable, the project can still be viable. The first release might use a controlled CSV import, a staff approval step, or one-way synchronisation. The key is to price that limitation honestly rather than assume an integration will be simple. Where workflows later require classification, document extraction, intelligent search, or repetitive-task automation, POLADO can scope AI Solutions & Automation as a separate, governed workstream.

4. Establish data ownership, migration, and quality

A new platform quickly exposes a basic question: which system is the source of truth? Identify an owner and authoritative source for each important object—customer profile, contract, product, price, payment, request, and user account. Also decide what data must move from old spreadsheets or systems, which records will remain archived, and how duplicates or incomplete records will be handled.

Ownership also applies to the delivered product. Before contracting, agree in writing who controls the source code repository, design files, cloud accounts, domains, database backups, third-party licences, and technical documentation. This is not a legal formality alone; it determines whether you can safely operate, extend, or transition support for the platform later.

5. Turn “secure” into testable expectations

“The application must be secure” is not a specification. Define security in proportion to the data and operational risk involved. State whether the platform needs email/password login, company SSO, or multi-factor authentication; which roles can view sensitive fields; which events require an audit trail; how long sessions remain active; and what backup and recovery expectations apply.

NIST’s Secure Software Development Framework recommends a risk-based approach that tracks security requirements and design decisions, protects software components, and plans for responding to vulnerabilities after release. OWASP ASVS provides a usable requirements baseline for controls such as authentication, authorisation, input handling, and security logging. For a higher-risk application, clarify the scope of verification: role access testing, core workflows, APIs, administration functions, or an independent penetration test.

6. Make the first release deliberately small and useful

An MVP is not a vague promise to build fewer features. It is the smallest release that creates a measurable outcome for a defined user group. Prioritise each requirement as:

  • Must have: essential for a pilot or first live workflow.
  • Should have: valuable, but can follow after the initial release proves the process.
  • Later: worthwhile, but dependent on adoption, data quality, or a later integration.

For a customer-service platform, the first release may include request creation, document upload, status tracking, staff assignment, customer responses, and a basic report. Advanced business intelligence dashboards, complex multilingual notification rules, and secondary ERP modules may belong in later iterations. Define success measures at the same time: shorter processing time, fewer manual entries, a percentage of requests resolved through self-service, or fewer operational errors.

7. Plan ownership and support after launch

Go-live is a transition into operations, not the end of responsibility. Your proposal should cover defect severity and response expectations, monitoring, backup checks, security updates, release management, and the process for small improvements. On the business side, nominate a product owner who can prioritise requests, collect feedback, and accept completed work.

POLADO’s Technical Support & Consulting can provide a practical post-launch model that separates operational responsibilities from planned product development. This helps prevent a custom platform from becoming an unsupported one-off project.

A concise proposal-request checklist

  • The business problem, target outcome, and why the current process fails;
  • user groups, roles, permissions, and approximate user volumes;
  • three to seven core workflows for the first release;
  • key data objects, source systems, migration needs, and data owners;
  • integrations, available documentation, test environments, and constraints;
  • security, audit, backup, and availability expectations;
  • MVP boundary, pilot group, target date, and success measures;
  • decision-makers, review cadence, and acceptance process;
  • expected post-launch support and ownership model.

A capable web application development company Baku should not price only by the number of screens. It should make assumptions, risks, dependencies, delivery stages, and exclusions visible. If you are deciding between a corporate site, customer portal, or custom business platform in Azerbaijan, speak with POLADO about a focused discovery and delivery plan before requesting a fixed-price build.