The Jaspero Client Handbook: Contracts, Team Setup, Code Ownership, and Handover

Who is Jaspero and what kind of work do we actually take on?

Jaspero is a software development agency that acts as the dedicated engineering team for product companies. We build and maintain full platforms: web applications in SvelteKit, mobile apps in React Native, backends on Firebase or Postgres, plus the admin panels, partner dashboards, and internal tools that surround them.

The engagements we do best are long ones where we own a product end to end. We were GlycanAge's engineering team for six years across 10+ interconnected systems, Plodovi's development team for four years across six systems, and part of Four's engineering team from the beginning of its buy-now-pay-later platform. That shape of work, one team responsible for the whole stack over years, is different from staff augmentation where you rent individual developers to fill seats in someone else's process.

We also take on shorter defined builds: an MVP, a rebuild of a legacy admin panel, an AI integration into an existing system. What we generally decline is work where we would be a third or fourth vendor touching the same codebase with no clear ownership boundary, because nobody ends up accountable for the result.

How do Jaspero contracts and pricing work?

Most Jaspero engagements are time and materials with a monthly retainer that covers an agreed team composition, invoiced monthly. Fixed-price contracts are used for tightly scoped, well-understood deliverables. Either way the contract includes an IP assignment clause, a mutual NDA, and a notice period, typically 30 days.

We prefer retainers for product work because product scope moves. A fixed price forces both sides to guess the full specification up front, and every change after that turns into a change request negotiation instead of a product decision. With a retainer you get a predictable monthly cost and a team that can re-prioritise the backlog every sprint without renegotiating the contract.

Fixed price still makes sense in specific cases: a marketing site, a well-specified integration, a migration with a known endpoint. When we quote fixed price we quote after a paid discovery phase, not before, because a number produced from a one-hour call is a guess dressed up as a commitment.

• • Retainer / time and materials: monthly fee for an agreed team, sprint-level reprioritisation, 30-day notice
• • Fixed price: used for scoped deliverables, quoted only after discovery
• • Discovery phase: a short paid engagement producing architecture, scope, and a realistic estimate
• • Standard clauses: IP assignment on payment, mutual NDA, GDPR data processing agreement where personal data is involved

How is the team staffed, and who will we actually work with?

You get a named team, not a rotating pool. A typical engagement is staffed with a lead engineer who owns architecture and is your main technical contact, one to three engineers depending on scope, and design or DevOps capacity brought in as needed. You meet the people before the contract starts and they stay on the project.

Communication runs through your channels, not ours. We join your Slack or Teams workspace, work in your Jira, Linear, or GitHub Projects, and attend your standups if you run them. If you have no process yet we bring one: two-week sprints, a written sprint plan, a demo at the end, and a short weekly written update so non-technical stakeholders can follow progress without attending engineering calls.

Continuity is a deliberate policy. Multi-year engagements only work if the same engineers keep the context, which is why the same people worked on GlycanAge's platform for six years. When someone does need to rotate off, we overlap them with their replacement rather than handing over a wiki page and hoping.

Who owns the code, the repositories, and the infrastructure?

You do. All source code, designs, and documentation produced for your project are assigned to you under the contract, and in practice we work inside repositories and cloud accounts that you own from day one. Jaspero holds no lien on your codebase and no licence you have to keep paying for.

Concretely, that means your GitHub or GitLab organisation hosts the repositories and our engineers are added as members. Your Firebase, Google Cloud, or AWS account holds the infrastructure and gets billed directly to you, so cloud spend is transparent and does not pass through our invoices with a markup. Domains, app store accounts, and third-party service subscriptions are registered to your company, with us as collaborators.

The one nuance worth stating plainly: some of our reusable tooling is open source and stays open source. JMS, our CMS, and several full production codebases are public on GitHub under permissive licences. If your project uses JMS, you get it under that licence like anyone else, and everything built on top of it is yours. There is no proprietary framework you become locked into and no vendor-specific runtime that only we can maintain.

What happens at handover, or if the engagement ends?

Handover is a defined process, not a data dump. Because you already own the repositories and cloud accounts, ending an engagement is mostly a matter of transferring knowledge and revoking access. We run a documented offboarding covering architecture, deployment, environment variables, third-party accounts, and known issues, then support the incoming team through their first releases.

We treat exit readiness as an ongoing property of the codebase rather than something assembled in the last two weeks. Architecture decisions live in the repository, environment setup is scripted, deployments run through CI rather than someone's laptop, and secrets live in a manager your team controls. If a new engineer cannot clone the repo and get it running locally from the README, that is a defect we fix during the engagement, not at the end.

For teams hiring internally, we also do gradual handovers: your first in-house engineers join the project while we are still on it, pair with our leads, take ownership of one system at a time, and we reduce our hours as they ramp. That is usually a far safer path than a hard cutover on a fixed date.

• • Access transfer: repository, cloud, DNS, app store, and third-party account ownership confirmed in your name
• • Documentation pass: architecture overview, service map, runbooks, environment setup, deployment steps
• • Walkthrough sessions: recorded technical handover calls per system with the incoming team
• • Support window: an agreed period of reduced hours for questions and incident support after the main engagement ends

How do you evaluate Jaspero before signing, and what do we expect from you?

Read the code. Several complete production sites we built are public on GitHub, along with JMS, our open source CMS, so you can inspect our actual commit history, structure, and test approach before any contract exists. Beyond that, ask for references from long-running clients and talk directly to the engineers who would be on your project.

There are honest limits to what we can show. Client platforms under NDA, laboratory systems, financial products, and internal dashboards do not appear in a public portfolio, so case studies describe architecture and outcomes rather than screenshots of everything. If evidence matters to your decision, the strongest signal is engagement length: clients who keep the same team for four and six years are a more reliable indicator than a gallery.

What we ask from you is a decision-maker with time. The engagements that go badly are the ones where nobody on the client side can approve a product decision inside a week, or where requirements arrive through three different people who disagree. One accountable product owner, access to the domain experts we need, and a willingness to look at working software every two weeks is genuinely most of what makes a partnership work.

If you want to judge our engineering before talking to us, start with our open source portfolio, which indexes JMS and five complete production SvelteKit and Firebase codebases on GitHub.