Choose a working model that fits.
A clear brief, an uncertain idea and an existing platform need different kinds of support. Start with the structure that matches the decisions you are ready to make.
Discuss your requirementsDiscovery: reduce uncertainty first
Choose discovery when the product direction is promising but the scope, provider capabilities or technical constraints are unclear. The work is organized around questions to answer, not a promise to build the whole product. Useful outputs include a workflow map, a tested integration assumption, a prioritized release plan and an estimate with its dependencies made explicit.
Custom build: deliver an agreed outcome
A project engagement fits a reasonably defined outcome: a new customer portal, an exchange workflow or an internal platform. Scope, milestones, acceptance and handover responsibilities are agreed together. This model works best when someone on your side can make product decisions and review progress. Requests outside the baseline are assessed before they change the delivery plan.
Source adaptation: extend a reviewed foundation
An existing source product can be a useful starting point when its architecture and license fit your intended use. We compare your requirements with the actual package before describing customization. Branding, languages, integrations and operational changes have different implications. The proposal should separate the source license, custom work, deployment assistance and any external service costs.
- Product fit and license review
- Customization scope and acceptance
- Upgrade and maintenance ownership
Ongoing engineering: evolve with your team
An evolving roadmap may benefit from a continuing engineering engagement with an agreed capacity, backlog and review rhythm. Maintenance can instead focus on a defined application and its operational needs. In either case, agree access, priorities, reporting, support boundaries and how work is transferred when the engagement ends. Availability and response commitments belong in the specific agreement.
Questions worth asking.
Which model is best when our brief is incomplete?
Start with a bounded discovery or a focused technical review. A useful first commitment should produce the evidence needed to choose a larger scope, rather than hide uncertainty inside a fixed feature list.
Can the working model change later?
Yes, by agreement. Discovery may lead to a scoped project; a launched product may move into maintenance or continuing development. The transition should include a revised scope, responsibilities and commercial terms.
Connect the next pieces.
Go deeper into the services and software foundations relevant to this conversation.
Tell us what needs to work.
Bring your idea, your current platform or a workflow that needs a better answer. We will start with the right questions.