Engineering culture isn't built through mission statements. It's built through the choices you make every day: who owns what, which technologies you pick, how you handle failures, whether your engineers can ship end-to-end or get blocked waiting on other teams. Over the past few years running engineering at Apify, I've grown the team to about 80 engineers across 12+ teams.
Here's what actually works for us.
Engineering to a T
I believe the best engineering work happens when you can see an idea through from start to finish. When you can spec it, build it, ship it, and watch it work in production - without getting blocked waiting on other teams.
That requires T-shaped engineers: deep expertise in one specific area (front-end, distributed systems, API design, whatever their strength is), combined with broad knowledge across multiple disciplines.
We hire these people, and that's also how we've structured teams at Apify to include a broad range of expertise. Spec to production. Frontend, backend, infrastructure - the whole stack, including designer, tester, and product manager.
By the way, the term T-shaped engineer was highly popularized recently in the context of AI, allowing people to build outside of their core expertise. As we’ve been building the Apify team this way for almost a decade, we had to shape our stack to enable it.
We've kept the codebase unified around TypeScript from infrastructure to frontend, combined with a very homogenous stack, specifically so your skills in one area don't prevent you from shipping in another. If you want to combine expertise with the autonomy to ship end-to-end, this is how we operate.
Build it, ship it, maintain it
In the long run, maintenance costs more than building. When teams own both and feel this pain, they naturally balance building new features with keeping the codebase lean.
At Apify, every team wholly owns its own code. They deploy, run, maintain, monitor, and fix features they’ve built. We have a platform team that owns some of the shared infrastructure, but the vast majority of the system is owned by the teams that built it.
This way, every team must strike a balance between the product and tech roadmaps. With this in place and product KPIs well-mapped to the team, everyone is empowered to make the right decisions.
Teams ship together
Team ownership is defined as part of the product, a user persona, user flows, a set of features, or a technical horizontal.
The team is the smallest unit in planning, responsibility assignment, and performance. If something goes well, the team is celebrated. If something breaks, the team owns it. We measure and discuss the roadmap delivery, performance, and other metrics only at the team level. It's up to the team to make sure every individual within the team delivers, too.
Sprint demos show what each team has built or achieved, not individual wins. This builds team spirit, a sense of ownership, and strengthens cooperation within the team.
Proud members of The Boring Technology Club
We're deliberate about technology choices. Everyone uses the same stack. We don't add new technologies often, because while it's easy to start using something new, it's incredibly slow to fully adopt it and reach a high level of maturity with a larger team.
Here's the math: if one team deploys its service to Vercel instead of Kubernetes, they might save a few hours on setup. But now everyone in our 15-person on-call rotation needs to learn Vercel and keep that knowledge current forever. Fragmenting your stack is expensive in the long run.
Read Dan McKinley's Choose Boring Technology essay and presentation. This piece changed how I think about technology choices.
"The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible. "
-- Dan McKinley
Does it sound boring? This makes you actually ship very fast, and that’s fun.
Slow yet continuous improvements
People and systems both hate sudden changes. But small, continuous changes? Those become habits.
Complete system rewrites rarely go well. They lose momentum, slip deadlines, and struggle to catch up with the production system that keeps evolving. We make changes every sprint instead, on both product and tech sides.
We rewrote our entire frontend from Handlebars to React over a year, doing a few components each sprint alongside regular product work. We migrated from Meteor.js to Nest.js and JavaScript to TypeScript over a year - 160k lines of code, rewritten line by line, without breaking anything or stopping feature development.
Small changes, deployed continuously, compound faster than you'd think.
Open culture and learning
Apify’s culture was very open from the beginning, and the same applies to engineering. We don’t have many closed doors.
There are multiple recurring meetings on various technical areas, including the frontend symposium, backend symposium, tech coffee, and web automation showcases. All are opt-in with an open agenda known ahead of time. Improvements are always welcome. For example, if there's something in the codebase that bothers you, this is a place to discuss it by first adding it as an agenda item. If the working group agrees, it gets added to the technical or product roadmap. We don't jump to new initiatives right away, so unless it's critical, they get fairly prioritized and eventually completed.
The technical roadmap is also a good way to grow your skills by driving a cross-team working group on a larger topic.
Incident post-mortem meetings are open to all engineers - you learn a lot from seeing how things break.
Automations and dogfooding across the board
We automate as much as possible so we can focus on what matters. This ranges from deployments and testing to organizing lunch groups - and we use our own platform heavily for it. See our blog post on How Apify uses Apify
Building for the long run
There's no silver bullet, and nothing works for every company. The most important thing is being authentic - build the culture around your people and hire people who fit it. Any persistent change requires patience for small, continuous improvements over dramatic changes, plus the discipline to stick with them.
If this sounds like how you want to build, check out our open roles.
