The honest answer to “what will this project require?” starts with questions. A portal used by one internal team is not planned like a multi-tenant SaaS product handling payments, permissions and integrations across several countries. The useful goal is not to publish a generic number; it is to understand the scope, timeline, responsibilities and risks before any commitment is made.
FKT Software does not publish generic offers for custom software. Every project is evaluated according to its workflow, users, integrations, expected timeline, operational risk and support needs. A proposal is prepared only after those details are understood.
Why each project is scoped separately
Two projects with the same number of screens can require completely different effort. One may use simple forms and a clean database. Another may involve legacy data, approval rules, permissions, document generation, third-party APIs and production support. Treating those projects as if they followed one standard delivery path would be misleading.
A responsible proposal should explain assumptions, scope boundaries, delivery phases and what is not included. It should not pretend that every web app, mobile app or SaaS platform follows the same delivery path.
The biggest planning risk is uncertainty
Teams often assume the number of screens defines the project. Screens matter, but uncertainty is more important. A project with clear users, decisions and acceptance criteria can be delivered more efficiently than a smaller idea whose workflow changes every week.
Discovery reduces uncertainty by mapping roles, data, integrations, exceptions and non-functional requirements before implementation begins. It should produce decisions, not a decorative specification.
Web application planning factors
A standard business web application may include authentication, permissions, forms, records, search, reporting and deployment. Scope changes significantly depending on:
- complex role and approval rules;
- real-time collaboration or notifications;
- large data imports and migration quality problems;
- document generation, OCR or AI workflows;
- offline operation or demanding performance targets;
- integrations with legacy or poorly documented systems;
- formal accessibility, security or regulatory requirements.
A customer portal may appear simple but require complicated account rules, hierarchy logic and ERP synchronisation behind the interface.
Mobile app planning factors
Cross-platform frameworks can reduce duplicated work across iOS and Android, but the backend, product design and testing still need to be planned. Scope grows with background location, offline sync, Bluetooth devices, media processing, subscriptions, push-notification workflows and store-compliance requirements.
If users do not need device-specific capability, a responsive web application may deliver the business outcome with simpler distribution and maintenance.
SaaS project planning factors
A SaaS platform is not merely a web app with a payment page. It usually needs tenant isolation, onboarding, subscription states, usage limits, administration, support tooling, audit logs and reliable upgrades across all customers.
International SaaS adds tax, localisation, data-protection and customer-contract considerations. Operational tooling should be planned from the beginning; otherwise every support request becomes a database task for a developer.
Integrations can dominate the scope
An integration with a modern, documented API may be straightforward. A legacy system with incomplete identifiers, manual exports and no test environment can require deeper planning. Before preparing a proposal, verify authentication, available endpoints, rate limits, webhook support, sandbox access and data ownership.
Do not rely on a vendor’s statement that “we have an API.” The specific workflow must be proven.
Maintenance and operating scope
Software continues to require care after launch. The right maintenance plan depends on change frequency, service level, infrastructure, compliance needs and how business-critical the system is. Maintenance can cover:
- dependency and security updates;
- monitoring, backups and incident response;
- browser, operating-system and API changes;
- small improvements and user support;
- performance and infrastructure optimisation.
Cloud hosting requirements differ sharply between an internal SME tool and media-heavy, AI-heavy or high-traffic workloads. Model usage, email, maps, payment processing and SMS should be reviewed separately before a proposal is prepared.
Local, nearshore and offshore teams
Team model alone does not determine project success. A lightweight-looking arrangement can be offset by unclear communication, weak product ownership, rework or slow decisions. A specialist team can be more efficient when the problem is well defined and delivery risk is high.
Evaluate timezone overlap, language, senior involvement, documentation, security practices, references and who will maintain the system. The best model is the one that gives the project enough product and technical judgement—not simply the largest number of developers.
How to plan a realistic project
- State the business outcome. Define the time, error or revenue metric the product should improve.
- Separate must-haves from later opportunities. A focused first release protects the delivery plan.
- Run discovery first. Resolve risky integrations and data questions early.
- Plan for unknowns. Identify assumptions that may change the scope or timeline.
- Include internal time. Subject-matter experts must review workflows and test releases.
- Plan ownership after launch. Decide who prioritises improvements and approves changes.
How FKT prepares a proposal
FKT starts by understanding the business workflow, users, integrations, data quality, delivery expectations and support needs. Only after that can the project be shaped into a clear proposal.
The proposal should describe the intended outcome, delivery phases, assumptions, responsibilities, exclusions and maintenance expectations. If an important dependency is unknown, it should be handled in discovery before the main implementation is committed.
What a credible proposal should contain
A credible proposal should state assumptions, included roles, deliverables, exclusions, third-party services, timeline, review points and what happens when scope changes. It should be specific to the project rather than based on a generic public offer.
FKT Software prepares project-specific proposals for European SMEs across web applications, mobile products, SaaS and internal tools. Share your workflow, users, integrations and target date through our project enquiry, or review our ways to work.