Onboarding: how we get started together

Onboarding follows three connected stages: Shape with Co-Dev, Build through Fixed Price Projects, and Care through Continuous Monthly Development. They aren't a required sequence. You can start wherever fits your project.

Co-Dev onboarding starts with project intake. You can provide a meeting recording, have a live conversation with AI or with us, or share existing documents.

It usually takes one to two weeks to go from intake to a working prototype. Before collaborative shaping begins, we hold one workshop with two sessions. The workshop is included in the prototype’s fixed price.

Already have a vibe-coded prototype? This path is called Go-Live. It starts with a paid assessment to determine what can stay and what must change for production, followed by a fixed-price production build scoped from the findings.

Your Project Manager contacts you to arrange the kickoff and introduce the people responsible for the work. Depending on the project, there may be more than one Project Manager, such as one specializing in mobile apps and another in backend systems. On bigger projects, a software architect joins from the start.

At the kickoff meeting we present the plan: what needs to be done, what you're responsible for, what we're responsible for, the timeline, and how to use our project management system. We also cover communication, time zone differences, and the best times to schedule meetings.

Large projects begin with Project Scoping, and onboarding happens once at that kickoff. The communication setup, meeting rhythm, and project management access carry straight into the production build, so there's nothing to repeat when the project moves from planning to development.

When you sign up online, your Project Manager contacts you the following working day to arrange access and schedule your onboarding meeting. For Care and Care Plus, work can often begin within 48 hours, once the first monthly payment has gone through. Care Ultimate starts with a planning meeting instead, where we plan the engagement before the first task or group of tasks is priced for your approval.

On all three plans, we give you access to our project management system and show you how to use it, and you receive a Monthly System Check. The first report arrives within a few days of your start, then a new one on the first day of each month.

System access and staging apply from day one of Continuous Monthly Development, from the start of the build on a Fixed Price Project, and during Co-Dev when the prototype touches an existing system. They aren't normally needed during Project Scoping unless the work concerns an upgrade.

System access

To develop, test, and deploy safely, we typically need:

• Admin access to your system, the website, webshop or application we'll be working on.
• Admin access to your code and deployment setup, FTP, GitHub, or whatever your solution uses.
• Read-only access to your analytics, Google Analytics or the tool you use, so we can see how changes affect your traffic and conversions.
• Access to Google Search Console and Google Tag Manager, where appropriate, so we can make the necessary adjustments for search visibility and tracking.
• Access to your staging server, if you have one.

Your Project Manager will walk you through each item before work begins; you don't need to prepare anything in advance.

The onboarding interview (only for Continuous Monthly Development)

For Continuous Monthly Development, we may sometimes first conduct an onboarding interview to understand your broader business context. This typically happens alongside your Project Manager introduction and covers four areas:

• Your development experience. Have you worked with other developers or agencies before? What worked well, what didn't? Any previous outsourcing experience?
• Your expectations and concerns. What challenges might get in the way of project success? Any concerns about our collaboration, location, or time zone differences?
• Project goals and success criteria. How will you measure success? Are there critical deadlines we should know about?
• Company background. Your company history, your role and decision-making authority, and any other context that helps us understand the project's strategic importance.

This isn't a one-sided conversation: we encourage you to ask questions about our company, services, and processes too. Afterward, we prepare a summary so everyone on your project starts with a shared understanding.

Staging server

As a general rule, every project should have a staging server: a copy of your system where changes are developed and tested before they touch your live environment.

If you don't have one, there are three ways to get one:

• Through your own hosting company. Most hosting companies offer staging environments, and we can advise you on what to request.
• Through 1902 Software. We can provide a staging environment for you. Your Project Manager will give you the price and handle the deployment.
• We set it up together with your hosting company. If you prefer to use your current hosting company, your Project Manager will collaborate with you and them to get it set up and configured.

For very small projects, it's possible to work without a staging server, but it's worth understanding the consequence. Without staging, changes are deployed directly to your live system. If something doesn't work as expected, it affects your live site rather than a test copy, and fixing it becomes more urgent and more visible to your clients. Your Project Manager will explain what this means for your specific project, and the decision is always yours.

Switching from another developer, freelancer, or agency always takes some effort, but it's something we do regularly.

Software review. Your Project Manager evaluates the existing source code quality and architecture, plugins and dependencies used, existing third-party integrations, and any modifications to the core CMS or platform. This identifies potential issues before we take over, giving you the chance to have your previous developer address critical problems first.

Access and account verification. We request admin login credentials and source code access, access to analytics and monitoring tools, and verification that key accounts (hosting, domain, analytics) are registered under your name rather than tied to your previous supplier. If helpful, we can coordinate directly with your previous supplier to obtain the necessary files and credentials.

For stalled projects, we ask for a list of incomplete tasks to assess fit. For ongoing maintenance takeovers, we typically start with a small batch of tasks, a mix of bug fixes and new features, to confirm we're a good match before committing to ongoing support.