Describe the project’s most important flow
Explain who uses the solution, what they need to do, what result they should receive and which systems may connect. That is enough for initial qualification.
Custom Project
For projects that don’t fit a standard format.
When a standard website or store isn’t enough because of an unusual workflow, user roles, data, or the way the business operates, we define the project scope individually.
Pricing model
Individual assessment
A fixed price becomes possible only after requirements, dependencies, risks and acceptance criteria are defined sufficiently.
You do not need a full specification at the start. Describe the users, the most important flow and the systems the project needs to connect with.
What kinds of tasks may fit Custom Project
These categories describe the nature of the work, not ready-made packages. Every project requires feasibility and scope qualification.
A non-standard website with custom logic
Connected forms, calculations, filtering, roles, processes or features beyond a typical business website.
Web application
A solution where users do more than read content: they complete tasks, work with data or follow a custom workflow.
User account, client area or internal tool
Login, roles, permissions, dashboards, statuses, documents or processes for selected users.
An integration-heavy or multi-step project
Connections to APIs, company systems, payments, data sources or a complex sequence of actions.
What you receive
Scope is not fixed in advance. The outcome is shaped by organizing requirements, designing key flows and implementing the approved version.
Defined requirements and boundaries
Users, roles, data, features, integrations, responsibilities, assumptions and acceptance criteria recorded in a controlled way.
Key flows and UX/UI
An interface designed around real user tasks, states and dependencies.
Approved implementation within defined scope
Features and integrations implemented after feasibility, inputs and responsibilities are approved.
QA against agreed scenarios
Testing covers defined roles, states, flows, integrations and acceptance criteria rather than a broad promise of perfection.
Controlled handoff and documentation
Access, ownership, instructions, limitations, recurring costs and next recommendations as defined in the SOW.
How scope is defined
Custom Project has no public reference package. We first need to understand uncertainty and define the artifact that allows safe progression to delivery.
Users, roles and permissions
Core flows and states
Data, data sources and processing rules
Integrations, APIs and external systems
Security, privacy and responsibility requirements
Acceptance criteria, stages and dependencies
A fixed price can be prepared once these elements are defined sufficiently. Before that, the right output may be a range, audit or discovery.
What is not assumed automaticallyA Custom Project inquiry does not automatically confirm feasibility, budget or timing.
- Unlimited features, roles, data and integrations
- Delivery without discovery when material unknowns exist
- Inclusion of specialist legal, security, tax or compliance audits
- Guarantee of third-party API or system compatibility and availability
- Bulk migration or data cleanup without separate assessment
- A fixed price before requirements and acceptance criteria are defined
What affects feasibility, scope and pricing
Number of user types, roles and access levels
Number and complexity of core workflows
Data model, sources and data quality
Integrations, APIs, documentation and test environments
Security, privacy, permissions and sector risk
Performance, accessibility and reliability requirements
Migration, replaced system and organizational dependencies
Requirements readiness and decision speed
How a Custom Project proceeds
Task qualification
We review the problem, users, business value, feasibility and main risks.
Uncertainty and dependency map
We identify missing requirements, data, systems, decisions, specialist review and blockers.
Audit or paid discovery where needed
A separate stage resolves unknowns and ends with an agreed artifact.
Defined scope and delivery route
Once requirements are defined sufficiently, a staged or fixed estimate, SOW and delivery plan are prepared.
Design, implementation, QA and handoff
Delivery follows approved flows, acceptance criteria, Change Requests and responsibilities.
Custom Project questions
When is a project considered Custom?
When the project’s core value depends on custom logic, data, user accounts, roles, integrations or workflows that cannot safely be treated as a standard website or store. An additional language version alone does not make a project Custom.
What can paid discovery produce?
Depending on the task: structured requirements, audit, risk map, information architecture, prototype, data model, technical plan, phased priorities or an estimate range. The exact artifact is recorded before discovery begins.
When can a fixed price be provided?
When key requirements, dependencies, responsibilities, inputs, integrations and acceptance criteria are defined enough for risk to be priced honestly. Before that, a phase, range or paid discovery may be more appropriate.
What needs to be known about users, data and integrations?
Who uses the solution, their roles, what data they enter and read, where data comes from and goes, which systems connect, and who owns access, compliance and maintenance. Passwords and secrets should not be sent through the public brief.
Possible alternatives
Next step
Describe a Custom Project
Write directly
- contact@vollory.com
- Vollory
- Telegram
- @vollory