I've spent the last 10yrs designing and building digital products at Canvs . We have always been a design first studio and only cherry picked engineering projects, despite always having a brilliant engineering team in-house. Our reason for this was simple, design projects rarely stay about design when you bundle Engineering with it; they become centred around engineering deliveries, and we never wanted to set ourselves up that way. Our engineering team was focussed on building internal tooling and external consultations on our design projects.
Things have changed, incredibly.
Projects that took months of engineering time now take weeks. Designers in-house now deliver coded interfaces upstream, and their understanding of engineering has improved many fold. Engineering has caught up on years of tech debt, and has built more products in house in the last 6 months than the last few years.
Agentic coding has laid the rails for a wave of internal building. If you work with an engineering team, you have probably noticed how much more effective they have become recently due to coding agents. And how hungrier they've become just sensing the possibilities.
My thesis is, given how empowered a single skilled developer is becoming with agentic coding, smaller companies will start building internal tooling that they held back from earlier.
It has been really messy
Till now, most internal tooling has been SaaS products. You pay a monthly fee to productize your internal processes. The decision takes some time, and then you live with annual contracts. Naturally, external products also come with bloatware that you never needed. You get features that are probably bundled in because someone else uses them, so maybe you might as well. You end up using 10% of them. Importantly, these tools don't talk to each other. So all systems and processes stay in individual silos. The integration layer emerges as a separate product. Companies already are cyborgs, but years of purchasing SaaS has made internal infra a chaotic monstrosity. Every year there have been new promises with a new 16th standard to clean it up.
However, the alternative was building your own tools Building internal tools that needed engineering was bigger ordeal. Digital products had become increasingly complex through the last 10 years. Engineering needed multiple specialists for backend, design, frontend, devops, security etc. The wall was high and engineering led projects became increasingly overwhelming for most teams. Planning and managing resources became a task of its own as projects became larger in size and criticality. As complexity in people and systems heightened, things became more opaque and unfortunately for such teams, more hand-wavy. Timelines failed all the time, products didn't come out as teams hoped they would, dissatisfaction was almost baked into the process. The sheer process of building the blocks of any half decent product was so intense and complex that it took the joy out of building. We started 'prioritizing' what's really worth the effort. Every time you wanted to build something internally, you always judged whether the effort involved made it seem like a huge distraction from your business and if you now were solving the wrong problem altogether.
For internal tooling especially, this (among other things) led to a 'no-code' movement that we briefly felt was gonna change things. Teams still need tools, and they couldn't wait for internal engineering prioritization to get what they wanted. However the no-code movement was a bit underwhelming.
But something completely different is here, now. Its never been easier to build your own stuff, and its getting better every month.
The raw power of agentic coding almost feels like retribution for the sheer complexity that digital engineering had assumed over time.
Why internal builds?
Internal tools and workflows typically sprout from generally accepted internal needs. They aren't hypotheses that need testing after a product is put out. They are typically the 'painkillers' from the analogy we all know of. They come with a problem statement, the very reason they are considered. Internal tools also have a limited user base that doesn't explode overnight. The decision complexity is low, the needs are pressing and visible, the results have RoI tied in.
But its also important to explain the need for any system at all. Companies might be tempted to follow the status quo on non-technical setups. Currently every company has some form or another of internal workflows. They appear as daisy chained processes across sheets, Whatsapp, notes etc. It was not tempting to build products that formalized this, unless teams lost a lot of time and efficiency around these linked flows. Internal products will be able to answer new problems and find new opportunities, beyond simple linked workflows. It's time firms can go beyond painkillers and build vitamins for themselves.
Building a dashboard to monitor your cashflow and checking where the year is headed in a way you operate.
Setting up a live monitoring system for your warehouse inventory.
Building proprietary research systems to power your investment teams.
Creating a product for managing your content sourcing and publishing pipeline.
You would want to build things that combine optimization with clear upsides. Investments happen when there's hope of extracting value over and above the risk free rate.
Being able to build new internal systems, ground up, that are obviously friendly to each other will be cathartic like good cable management discipline. Importantly, building your own tools provides ownership of the entire infra and a level of malleability that you cannot achieve by daisy chaining external tools. You can build what you need, when you need and however you like.
Tools before agents
We love the agentic future, but for those agents to run around doing jobs, they'll need teeth. Internal tooling is the teeth. Agents will require APIs, organized data sources, audit trails, permissions, tools to call. Without internal tooling agents won't be useful. Building agents into a system without tools is just early. Consequently, the form factor of tooling might also reflect agentic designs.
Knowing what to build
Judgement of what is required for a business is critical. This will prevent teams from building bloat and slop. However for the cases that you are confident about, it should be okay to have some decision tolerance. Given the velocity of shipping that can be achieved, decisiveness is allowed a generous error rate. Iterations can be rapid, teams can reach consensus continuously post testing. Given these are internal teams, users won't just arbitrarily scale and the testing sample set will be fair in representation. It's important to however state that among the tools that teams would want to build the shape of such tools could become complex to imagine for non-product people. Requirement docs often end up being what people theoretically believe everyone wants, but realize later they hardly need. Teams are often deluded about the experiences they need and find out later that they overestimated/misunderstood their feature requirement. Failing fast in contained iterations will be therefore central to the process.
What we need for this future
A company needs a judgement layer and an engineering oversight layer. The judgement layer is the "what to build" part above. Any company that wants any part of the promised future, needs to invest in at the very least a small engineering team, in-house or embedded partners. A small team of good engineers who are suited for the scale of operations you run is enough to lift way above their combined weight of skills in internal tools and automations. This team is not always going to be a hired internal team. This is because the time within which you can hire, you can actually get a good embedded external party to just make you what you want. Gradually, over time, companies might want to invest in an internal oversight layer. However for purely non-engineering companies, this might still not be too lucrative.
Explainability, simplicity and a reduction in technical opacity
As teams take interest in building up their own technical skeleton, rapidly so, they will want to understand what's being built. People who are more inclined will actually start learning a thing or two about the technical infra. This time it's not features, it's the engine they'd want to know about. Thankfully agentic systems are able to explain themselves, after all they have an answer engine underlying them.
Which brings me to the next thing, the overton window of tech speak is shifting. Non tech people will start speaking in technical terms, often being just vaguely correct, but tech speak will expand. We are already talking GPT, GPUs, tokens, compute, etc. things we never did before. Its a good thing as far as knowing your systems is concerned, since you will ask directionally right questions.
Diffusion via vendors
When innovation is inward facing, diffusion will largely be via external partners and attrition. This puts such partners in a unique position of industry knowledge that they absorb.
Vertical systems
As companies formalize their unique internal processes, they will form a pattern of vertical integration in internal systems. Systems that work the way the company wants, talk to each other and focus on the individual vectors teams are keen on controlling. This will open up a new layer of observability into internal processes and hence completely different levels of control. Earlier, companies like SpaceX have built their own 'digital nervous system'. That will be tempting to build for most companies now as individual systems inside come alive. As the friction to build new products diminishes, teams will get more creative and try to extract more value from their tools. The tools they craft will shape their abilities and hence become an important part of their identity.
Some custom sample tools we have built internally
Finance oversight layer: Cashflow, predictions, conversational interface on top. We paused our plans to hire thanks to this
Design systems production: Crunches the creation time for hand crafted systems to a fifth.
Full fidelity prototyping workflows: Crunches front end engineering timeline many times over and deliveries are now in code.
Content ingestion, signals, writing and publishing: 2 people handling the work of 5.
An ambient intelligence system: Picks up signals emerging from various parts of our studio for our CDO to have constant observability.
Agentic project management for Design Managers: Allows our DMs to focus on design instead of the management of projects
Company auth: Security and bringing all internal tools together with access, notifications, groups baked in
Internal secondary research, publish and distribution: Reduced weeks of secondary research work to hours. Related knowledge dedupes and hence builds on top.
A lot of the tools above actually qualify as Agent in the loop as opposed to the other way around. All this happened in the last 6 months.
It's time to (re)build.
