Cloud & infrastructure
Infrastructure your team can run, understand and develop. For companies and agencies that run many websites and services in the cloud, where costs and risk grow faster than the team.
The first conversation is free: 30 minutes online, no preparation and no commitment.
Who this is for
Companies with many websites and brands
A dozen or more sites built in different years, by different agencies, on different hosting. Marketing waits for IT, IT does not know who owns which site, and every update is a separate project. If the CMS and the publishing process are part of the problem, see digital products & platforms.
Teams where deployments depend on one person
One person knows the passwords, the servers and the order of steps. Their holiday stops deployments, and their departure would be an incident. The documentation lives mostly in their head.
Organisations facing a migration or a cost review
The cloud bill grows every month and nobody can say what could be switched off. Or you are planning a move from a dedicated server or between clouds and want to know the dependencies before anything is touched.
What we usually find
The same problems come up in most environments we review:
- Machines running around the clock for sites that a few hundred people visit a day.
- CMS admin panels reachable from the public internet, protected by a password alone.
- Access granted years ago to people and agencies that no longer work with you.
- Backups that nobody has ever tried to restore.
- Every site configured differently, so none of them can be updated in bulk.
- Several billing accounts and no single place where the whole cost is visible.
Most of these can be fixed without rebuilding everything. We start with the ones that cut cost or risk the fastest. The last two are often also a compliance question: who has access to personal data and on what basis, which is part of our digital compliance work.
What we work on
Architecture & migrations
We map services, data and dependencies, choose the target architecture and plan the move in stages. Each stage has acceptance criteria and a way back if validation fails.
Delivery & operations
Repeatable environments, CI/CD, monitoring, backups and recovery procedures. Routine tasks that can be written down as steps become automations, so the team runs them without manual work.
Costs & resource use
We review what is running, why it is running and how it is billed. Right-sizing, static publishing and workloads that run only when needed are options we assess against actual usage.
What we have done before
The founders’ experience from projects delivered before the company was set up, directly and in cooperation with agencies, for large organisations and startups. More under achievements.
- Infrastructure and operating costs down by 80% after a platform rebuild, while the number of sites, integrations and automations kept growing.
- More than 100 virtual machines: every site on its own isolated machine, which starts for the time of work and switches itself off when nobody needs it.
- More than 6 years without a security incident on the sites we ran: the admin panel behind a private tunnel and a sign-in gate.
- More than 250 cloud projects under one model of roles and permissions, using more than 40 Google Cloud and Firebase services.
- A technical team of a few people running dozens of sites. Scale comes from architecture, not headcount.
Example: many brands, one platform
A typical starting point and what we built from it. The client’s name, figures and configuration details are something we discuss in a meeting.
Before
All brand sites in one environment: a shared server, shared passwords, one line on the invoice. A failure or break-in on one site threatened all of them, and every update needed a maintenance window for the whole platform.
After
Each site as its own Google Cloud project: its own machine, its own permissions, its own cost visible on the bill. Content published statically, the CMS panel behind a private tunnel, machines switched on only while editors work.
Result
Infrastructure and operating costs down by 80% while the number of sites grew. More than 6 years without a security incident. One model of roles and access for the client, agencies and media houses, run by a team of a few people.
Three steps, each one you can stop after
Free consultation
30 minutes online. You tell us what you have and what hurts. We tell you whether and how we can help, and what we would do first. No preparation, no access to the environment, no commitment.
Infrastructure review
Fixed scope and a fixed price agreed before we start. Up to two weeks from receiving read-only access. We change nothing at this stage. A report and a review session with your team.
Implementation
Changes from the report delivered in stages, with acceptance criteria and a price agreed for each stage. After every stage you decide whether we continue or your team takes over.
What the review covers
- Inventory: services, machines, domains, billing accounts and who has access to what.
- Costs: what costs how much and why; which items can be switched off, reduced or replaced with static publishing.
- Risks: single points of failure, untested backups, public admin panels, dependence on one person.
- Plan: a list of changes ordered by effect and effort, with estimated savings and a proposed sequence.
- A review of the findings with your team and a decision on whether and what to implement next.
This is what a fragment of the cost section looks like. The figures are illustrative, the layout is real:
| Item | Current state | Recommendation | Effect |
|---|---|---|---|
| Company website, 4 vCPU machine | Runs around the clock for a few hundred visits a day | Static publishing, machine on only while editing | Machine cost down by about 90% |
| Database shared by 12 sites | One instance, a failure affects all of them | A separate database in each site’s project | Failures and costs isolated |
| CMS admin panel | Public, password login | Private tunnel and sign-in with company accounts | Attack vector closed |
| Access | 23 accounts, 9 inactive, 3 shared | Remove inactive ones, roles instead of shared accounts | Auditable permissions |
| Backups | Daily, never restored | Restore test every quarter, written procedure | Confirmed recovery time |
The review is also the first stage of a migration: the inventory and the dependency map are what you need anyway before moving anything.
What stays on your side
We work in your cloud accounts, on your domains and in your repository. Administrative access stays with the company, not with the contractor.
- Environment configuration and deployment procedures written as code, not held as one person’s knowledge.
- Operational documentation: what runs, where, who has access and how to restore it after a failure.
- Tidy permissions for the team, agencies and partners, reviewable in one place.
- Knowledge transfer to your team, as workshops where useful, or an agreed monthly scope of continued maintenance.
How a migration runs
Seven steps, always in this order. Each has a criterion for moving on, and the current environment keeps running unchanged until the switch, then stays as the copy to fall back to. We have moved sites and shops: WordPress and WooCommerce, Drupal, Joomla, Pimcore, agencies’ in-house CMSs and e-commerce platforms, between shared hosting, dedicated servers and clouds.
Inventory of domains and services
Every domain and subdomain, DNS record, certificate, site, service and integration: e-mail, forms, payments, analytics, APIs. Who pays for what and when it expires. The result is one list that did not exist before.
Access audit: code, databases, servers
Who has access to repositories, hosting panels, databases, servers, the domain registrar and DNS. We recover what only the previous contractor holds. Without full access we do not start moving anything.
Backups
A full copy of every site’s files, databases and configuration before any change, stored outside both environments. We test the restore on a staging environment instead of assuming it works.
Moving the infrastructure
The target environment is built next to the current one, from configuration written as code, in your accounts. Sites come up under test addresses and are switched in batches in an agreed window, outside the team’s working hours. Rollback is a DNS change, because the old environment stands untouched.
Verification of sites, e-mail and forms
A checklist for every site: pages and redirects, CMS login, forms with delivery confirmed, e-mail (MX, SPF, DKIM and DMARC records), in shops a test order through the cart and payment, integrations, certificates, performance. Results go into a report, not into the sentence “it works”.
SEO check after the migration
URLs compared before and after, 301 redirects for changed addresses, sitemap, robots.txt, canonical URLs, structured data. Search Console without new indexing errors, rankings and traffic watched over the following weeks.
Documentation and emergency procedures
What runs where, who has access, how to restore a site from a backup, whom to notify and how. Handed over in your repository together with the access. This is what it looks like: a sample handover documentation.
How operations work
Operations start after the review: we know what we are taking over and it is written down who is responsible for what.
A review before the handover
We do not take responsibility for an environment we do not know. The review gives an inventory, a list of risks and a plan; the scope of operations and the split of responsibilities follow from it.
Tickets and response time
A report goes to a system, not to one person’s inbox: a ticket is created, the people on duty are alerted and verification begins. A critical failure: by phone, around the clock, response within 15 minutes. Everything else: by e-mail or form between 8:00 and 20:00, response within an hour. These times are written into the contract.
What we do not promise
A time to fix. It depends on the cause, and a promise without cover is worth nothing. We do guarantee a status update within an agreed time and, as the last resort, restoring the service from a backup within a time confirmed by restore tests.
Monitoring, backups and restore tests
Availability and health monitoring with automatic alerts. Backups with an agreed retention. Regular restore tests with a written procedure, because a backup nobody has restored is not a backup.
No dependence on one person
Configuration and procedures written as code in your resources, operational documentation, on-call duty shared between the founders and partners. Usually two or three people per client, on purpose: generalists, not specialists in one tool. The risk we remove at our clients cannot exist on our side.
Responsibility for mistakes
A responsibility matrix in the contract: infrastructure, updates, backups, monitoring, content, third-party services, changes made outside the process. A mistake on our side we fix at our own cost, including any additional elements the fix needs, within our fee. A mistake on the client’s side is the client’s responsibility, but we help even then: additional specialists, an additional audit, a repair plan.
Technology follows the workload
We work with Google Cloud Platform, Firebase, Kubernetes, Linux and CI/CD tooling. The choice depends on the workload and the team that will maintain it. A small static site and a platform with several services need different solutions. We do not move things to the cloud for its own sake: sometimes the best result is switching off half of what is running. When no ready-made tool exists, we build it as custom R&D, such as panels for managing machines or static publishing from a CMS.
FAQ
Are you a new company?
The company is, since 2026; the practice is not. Jakub has signed contracts in his own name since 2009, has run a business since 2016 and large digital environments since 2014; Agata has run digital projects for more than ten years. The tools and documentation of the previous decade were brought into the company under copyright transfer contracts. The timeline is on the founders page.
Do we have to move everything?
No. Often the best result comes from switching off unnecessary resources and tidying access in the current environment. Migration is one option, not the starting point.
Will we lose control of the environment?
The opposite. We work in your accounts, document every step, and administrative access stays on your side from day one.
What about our current agency or IT department?
We can work alongside the existing team or take over a clearly defined part. The split of responsibilities is written down before we start.
Is a small company too small for you?
No. One site and a few services are often the fastest return. We size the scope to the environment, not the other way round.
How do you charge?
First consultation: free, 30 minutes online. Review: fixed price. Implementation: stages with acceptance criteria and a price agreed for each stage. Operations: a monthly scope agreed after handover.
What about data and confidentiality?
We sign a non-disclosure agreement and a data processing agreement before receiving access. Access is personal, limited to the scope of work and revoked when it ends. How we handle data from the contact form is described in the privacy policy.
Can you provide references?
The sites we have run for years belong to organisations that treat the identity of their infrastructure provider as part of their own security, so we are bound by non-disclosure agreements. In a meeting we discuss scale and architecture without names, and with a client’s consent we arrange a reference call. A list of public references is in preparation.
What about a failure at night or at the weekend?
A critical failure is reported by phone, around the clock, with a response within 15 minutes. Reports by e-mail or form are handled between 8:00 and 20:00 with a response within an hour; those arriving at night wait until the morning, unless monitoring detects the failure earlier and raises the alert itself.
Does the experience described on this site come from the current founders’ projects?
Yes. Every figure and example comes from projects Jakub and Agata ran personally before the company was founded, directly and together with agencies. We do not describe the track record of people who are not on the team.
Who is financially responsible for mistakes during a migration?
For a mistake on our side, we are: the fix and everything needed to remove its consequences is done at our own cost, within the agreed fee. This is not liability for damages, and we say so plainly before the contract is signed. Mistakes on the client’s side are the client’s responsibility, but we help to fix them, including finding additional specialists and running additional audits. That is why we run a migration so that a mistake is not expensive: the old environment stays untouched until the observation period ends, and rollback takes minutes.
How many sites have you run?
A portfolio of sites for several dozen brands of one client over many years, and a dozen or so sites of other companies, together with their measurement stack: Google Analytics, Tag Manager, advertising accounts. Names and figures under non-disclosure we discuss in a meeting.
Are you responsible for the hosting and infrastructure yourselves?
Yes. We set up organisations in Google Cloud Platform, Google Marketing Platform and Google Workspace from scratch, with their billing accounts, and were responsible for keeping them running. The accounts belonged to the client, the technical responsibility to us.
Do you manage WordPress and other CMSs?
Yes. We build sites from scratch, audit them and take them over from other contractors: WordPress, Drupal, Joomla, Pimcore, agencies’ in-house CMSs, e-commerce platforms. A site that is with us is our responsibility: updates, backups, monitoring, security. The most common migration target is WordPress, because developers, agencies and companies themselves know it, so it does not tie you to one contractor.
How many people serve one client?
Usually two or three, on purpose. We work with generalists: full stack instead of a developer of one framework, sysops and devops for GCP, Azure and AWS instead of an administrator of one cloud, a person who opens Figma, deploys a change in WordPress and runs the conversation with the client instead of a project manager for meetings only. We scale with scope and tools, not headcount.
What were the SLAs and failures like at previous clients?
Contractual SLA: one hour to respond; in practice the response came the moment the report arrived, which is why we now offer 15 minutes for critical failures. Sites behind a CDN and with more than one provider, so that the failure of one element does not stop the rest. Monitoring and clients reported no unavailability in recent years.
Let’s look at your infrastructure
Tell us how many sites and services you run, where they run and what worries you most: cost, risk or dependence on one person. We will propose a time.
The first conversation is free: 30 minutes online, no preparation and no commitment.