Fixed-scope software and AI solutions. Decide with something in your hands.

One packaged engagement with four named deliverables and a defined end, agreed in writing before the work starts. It exists so you can get a decision, a working pilot or a passed review without first committing to a multi-month build.

It is also why the AI offers here are fixed-scope: an assessment or a 30-day pilot answers a question, and a question can be scoped where open-ended research cannot. Whatever it produces is yours to act on, with your own team or another vendor if you prefer.

A service is a capability we staff for as long as you need it: custom software development, AI engineering, QA, dedicated teams. A solution is one fixed-scope instance of that capability, with defined deliverables and an end date. A solution is designed as the front door: buy the answer first, then continue with a service engagement for the build.

It depends on the offer and on how much is in scope, and we confirm the figure on the scoping call once we know. What is fixed is that there are no open-ended discovery hours: the scope and the deliverables are agreed in writing before work starts.

We do not publish project price bands: a band that fits every environment fits none of them. We bill three ways across all our work:

• time and materials, billed hourly and quoted per project
• fixed price, outcome based and quoted per project
• team extension, billed monthly per team member

Between four and ten hours of your team's time in total, depending on the offer. Most of it is front-loaded: agreeing what is in scope, arranging access, and putting the people who know the system in front of us for short conversations.

Three of the six publish a fixed window: the AI Readiness Assessment runs two weeks from kickoff to readout, the Conversation Intelligence Pilot thirty days, and MVP in 6 Weeks six.

The other three set the timeframe at scoping, because the scope is what decides it: a security review of one product against one buyer questionnaire is short, and the same review across several environments and regulations is not. You get the duration in writing before you commit, not midway. Separately, most engagements start within two to four weeks of signature.

For the assessments and audits, no. We read: the code, the documentation, the cloud billing and architecture, and for the conversation pilot a sample of real calls or meetings. Nothing is written back to your production systems and no integration is built during them.

The three that build are different. What the pilot and the MVP connect to is agreed as part of the scope before work starts. A rescue goes further still, because getting a stalled project shipping again means working inside the systems that run it, which is scoped and agreed separately in writing.

Where an assessment finds that the integration surface is the blocker, saying so is the deliverable.

NDA before any access. For the assessments and audits we work from read-only, least-privilege access, agreed with your technical contact before anything starts. A rescue or a build engagement is different by nature and its access is scoped separately, in writing.

Everything it produced is yours to act on however you like, including with your own team or another vendor. If you continue with unicrew, the scope and the costed next step you already have become the starting point for the build, so no discovery work is repeated.

Pick by the problem in front of you rather than by the technology.

• If you need to know whether AI will pay off, start with the AI Readiness Assessment.
• If you need something users can touch, start with MVP in 6 Weeks or the 30-Day Conversation Intelligence Pilot.
• If something already in production is stalled, fragile or expensive, start with the Legacy Software Rescue or the Cloud Cost and AI-Readiness Audit.
• If a buyer or an auditor is blocking a deal, start with the Security and Compliance Readiness Sprint.

That is a valid outcome, and it is cheaper to learn in two weeks than in two quarters. Where the blocker is data quality, architecture or access rather than ambition, the deliverable says so plainly and becomes a sequenced plan: what to fix, in what order, and what it unlocks.