Fractional CTO services

The executive who owns a company's technology can take one of three forms:

• Fractional CTO: an experienced technical leader who works with your company part time. They set the technical direction, decide on the architecture and guide the engineers, but they are not a full-time employee.
• CTO as a service: the same role delivered by a company instead of by one person.
• Full-time CTO: a technical leader employed inside your company.

Startups and scale-ups without a technical leader look at the first two when hiring a full-time CTO is not the right step yet. Our model is the second one: Order Group delivers the role as a company, so the person who sets the architecture works next to the engineers who write the code.

A company needs a CTO when technical decisions start to shape the business and nobody owns them. You can see it in a few places:

• A product has to be built, and its architecture is still open.
• Estimates arrive, and the business side cannot verify them.
• Technical risks live in people's heads instead of in the plan.
• The team writes code without agreed standards or a review process.
• Decisions about technical solutions stall because nobody has the last word.

A founder with an idea and no technical partner runs into the first two early. A scale-up that is scaling a running product with a growing team tends to run into the last three. Each of these gaps falls under a duty of the role, and in our projects the Project Tech Leader holds those duties.

Choosing the Project Tech Leader is the first item on the checklist we run when a project starts, and the Project Manager makes sure the person is assigned. Every project has three roles: the Project Tech Leader, a Product Owner and, optionally, a Scrum Master. The rest of the checklist covers the working method, the kick-off with you and the onboarding of the team.

The role requires frontend and backend knowledge and proven experience in conversations with clients.

The Project Tech Leader stays with the project as it grows. They onboard new team members, make sure components are reused together with design, and review user stories and acceptance criteria for clarity and feasibility. If the project lacks a technical skill, they can propose a change in the team's composition.

When the direction is unclear, the Project Tech Leader first consults experienced developers and other Project Tech Leaders. When the Project Tech Leader is away, a deputy steps in, named in agreement with the delivery team and with the CTO's consent, so technical decisions do not wait for a holiday to end.

The CTO's authority reaches past a single project. A change in the tools we use to write and deploy code, AI tools included, needs the CTO's approval. The heads of the frontend and backend teams propose such changes after analysing technology trends.

The entry point is the free discovery workshop: one meeting, run by the engineers who later build the product. Based on it, we prepare a basic proof of concept or mockup that lets us estimate cost, time and team composition. An extended discovery is a separate, wider scope, and its full set of artefacts includes a roadmap. You can read more on the page about our consulting and discovery services and on the discovery workshop.

After the start, the work runs in Scrum with the Product Owner on the client's side. We work in your tools if you prefer: at Skyfri contact goes through MS Teams, Outlook and Slack, and from October 2024 the tasks live in the client's Jira. At KYOTO it was Slack and the client's Jira. You get a monthly report of the time worked. More on the how we work page.

Skyfri started with a Technical Feasibility Study in November 2023: market analysis, a feasibility study and a technical specification. Architecture and the implementation of the energy management system (EMS) followed, and the solution went into production in June 2024.

The technical decision that shaped the architecture was how devices and data communicate. The system had to collect signals from several sources: energy trading, the grid operator, the battery with its power management system, and energy meters. The operator's signals limit export to the grid, and the meters sit on the grid, battery and photovoltaic side. The alternative was to replicate the data to a dedicated server. We chose Azure IoT Hub and Edge, because communication is built into the Azure suite: data is streamed and devices are controlled centrally on the Azure side.

The scope included communication modules for Modbus, an industrial protocol, and the control of batteries and PV panels, with operating modes such as peak shaving, which cuts power peaks, and keeping the battery's state of charge (SoC) at a set level. A logic module steers the battery, and data pipelines feed the ETL (extract, transform, load) processes. The stack is React, Python asyncIO and Databricks, where the cloud backend and the ETL run.

We plan the work with the client in cycles, at Big Room Planning sessions where the next stretch of work is agreed. At Skyfri the team joined in January 2024, just before a session at which the first work was planned. The next one, in October 2024, covered the period from October 2024 to February 2025.

Three projects show the technical role at work:

• Skyfri. A new IoT system with the EMS described above, which steers 7 plants with more than 5 MWh of storage and more than 4 MW of battery power. Read the Skyfri case study; it sits in our energy software hub.
• KYOTO (Norway). In the first stage our team built an MVP, and Maciej Sułek, Co-founder & CTO, was the Project Tech Leader. We came back to the project in 2024, and product development ran from January to December 2024, in Scrum, in Python, React / React Native and AWS. The scope covered cloud infrastructure, a planning and simulation platform, a battery management system for a molten-salt thermal battery, and integration of external data such as weather forecasts and current energy prices. It also included SCADA (supervisory control and data acquisition) dashboards and a web interface. Read the KYOTO case study.
• Mudita. An app store for the Mudita Kompakt, a phone with an e-ink screen, and a platform for over-the-air (OTA) updates, built in Scrum with Java, Kotlin, Python and the Android Open Source Project (AOSP). Maciej Sułek has been the Project Tech Leader since July 2022 and prepared the technical requirements himself. He also supports the client's processes in this project.

The CTO role is played by Maciej Sułek, our Co-founder & CTO, together with the Project Tech Leader of each project. Maciej co-founded Order Group in 2013 and in the first years of the company led projects as a tech lead. When a project needs it, he writes epics, user stories and CI configurations himself. You can read his profile on the expert page.

Teams build with us because the plan and the build stay with one group of people. The engineers who run the discovery workshop also build the product, the Project Tech Leader takes part in your meetings, and a deputy approved by the CTO covers for them when they are away. Maciej was the Project Tech Leader in the first stage of KYOTO and is the Project Tech Leader at Mudita, where he wrote the technical requirements himself. Order Group is a software house from Warsaw. Since 2013 we have delivered 160+ projects in 15+ industries, rated 5.0/5 on Clutch from 18 verified reviews.

Book the free discovery workshop or write through the contact form. We answer within 48 hours on working days.