I don't rebuild good software

Anyone starting on a custom system usually has software in place already, such as an accounting package or a planning tool. In the first phase of a project we decide what happens with it: which packages get connected and which ones the platform replaces. That choice looks modest but determines how your team works every day for years to come.

That evaluation mainly concerns the packages that touch the core of your workflow. Proven tools for separate processes are never rebuilt. Accounting software or a calendar like Google Calendar usually works watertight, and rebuilding something like that would bring in needless complexity. The custom work focuses on the specific workflow of your team, and the proven tools get connected to it.

For the packages within that core workflow, the bar for staying is deliberately high. An integration is an investment in its own right. It has to be built and maintained. It also anchors the package deeper into your operation and makes it harder to replace later. That investment is only justified for a package that fully supports your way of working and runs smoothly and reliably on top of that.

The criterion behind this is that a tool has to be simple and powerful at the same time. A cumbersome tool gets avoided in practice and the data inside it goes stale by itself. A tool that only handles part of the work pushes the rest into spreadsheets and loose lists. In both cases the workarounds return that the platform was meant to eliminate.

The same goes for the opposite move: migrating all your data to a new package that only covers part of the operation. Such a migration is largely manual work. With a half solution that work is lost twice: first during the move and again when the full solution arrives after all.

An integration is also not the same as automation. Some packages only allow data to be pushed or pulled by hand. That is already a considerable improvement over retyping. Still, the software on the other side determines how deep an integration can go: modern packages open up their data and older ones offer little more than an export. That is why this analysis belongs in the first phase.

In practice I have built integrations between websites and real estate software, notifications that arrive in Slack automatically, Notion as client management and content that flows from a management environment straight to the website. Always with the same goal: data that lands in the right place without anyone touching it.

Which packages stay and which get replaced is something we decide case by case in the first phase of the project. The goal is always the same: working less hard by working smarter.