Ownership and sign-in
A GitHub organisation or GitLab group held by the company, sign-in via Entra ID or Google Workspace, and two-step verification for everyone. When a working relationship ends, you remove access in one place.
Take a furniture exporter in the Savinja valley. One employed developer and two self-employed contractors look after an online kitchen configurator, a trade portal for dealers in Croatia and Italy, and the link to Pantheon. Each brought their own habits: one works in GitHub, another in GitLab, the third uploads files over FTP. Shipping a new version means someone copies files to the server by hand in the evening and hopes all is well by morning. IDE and AI assistant subscriptions sit on private cards, and the payment gateway key was emailed around months ago. None of this is unusual for a small team that grew as it went. Trouble starts when one of the three moves on, or when a large buyer sends a security questionnaire before signing. Apply does not answer that with a heavyweight platform. We bring a handful of clear rules: one platform owned by the company, a single way of releasing, secrets kept in one place, and subscriptions where you know exactly who uses each seat. Everything is arranged remotely. You take out the subscriptions yourself, either with the vendor or via a reseller you prefer.
We size the work to the team. Two developers do not need the machinery a team of twenty would, yet even a tiny team needs clear ownership, traceability and safe releases.
A GitHub organisation or GitLab group held by the company, sign-in via Entra ID or Google Workspace, and two-step verification for everyone. When a working relationship ends, you remove access in one place.
A protected main branch, at least one reviewer besides the author, and an agreed naming scheme for branches. With two or three people this is not red tape; it is the only way someone other than the author understands a change.
GitHub Actions or GitLab CI running the tests on every change and, once approved, pushing the build first to staging and then live. If something breaks, rolling back to the previous version takes one click.
Payment gateway keys, database passwords and API tokens move out of inboxes, chats and text files into a secrets manager. Anything that was ever exposed gets replaced.
Automatic alerts about vulnerable library versions via Dependabot or Renovate, and a software bill of materials. We also look at licence terms, because some open source licences oblige you to publish your own code if you distribute the product.
Which assistant, on which plan, for which repositories, and whether it may see code covered by a non-disclosure agreement. A short written policy the team signs off.
A list of every development subscription with its per-seat price, renewal date and user. Idle seats are dropped and invoices are made out to the company from then on.
The work is broken into small pieces so development never stops. There is no day on which the team has to wait for us.
Ninety minutes on a video call covering how code is written and shipped today, where secrets live and what bothers the team most. A short plan comes out of it.
Repositories are brought into the company organisation with their full history; permissions are tidied and branch protection is switched on.
We set up automated builds and releases, migrate secrets into the vault and rotate any keys that had leaked.
After a month we sit down together, see what has worked and what gets in the team's way, and adjust the rules.
Who owns the code is a legal question and a technical one at the same time. If a self-employed contractor writes software for you, copyright in that code depends on the contract you sign with them, not on whose account the repository sits in. The reverse holds too: even with a watertight contract, you are stuck if the code lives in the private account of someone who no longer replies. We handle the technical side; have your legal adviser review the contract.
Not necessarily. If the team is productive in GitLab, it stays in GitLab and we simply sort out ownership and rules. We only move platforms for a good reason, for example a customer insisting the code be hosted on your own server in the EU, or three platforms for three people.
Each one gets access through an account in your business identity or as an external collaborator, limited to their own repositories and with an expiry date. Production secrets stay out of reach and their changes go through review. A contract assigning the rights should be drafted by your legal adviser.
That depends on the plan and on your client contracts. Business tiers generally promise that your code is not used to train the model, and we verify the terms when choosing, since they change. For projects under strict confidentiality agreements, the policy can simply say the assistant is not used there.
No. Apply is not a sales partner of any developer tool vendor and earns no commission. We advise on which subscriptions and how many seats you need; you sign up yourself, in the company's name.
Our work is charged at €50 per hour plus VAT. After the workshop you get an estimate, or a fixed quote where the scope is clear. Subscription fees go from your company straight to the provider.
Let us know how many people write code, where it is kept today and how new versions go live. We will reply with a short plan and an estimate of the work.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.