Compendium

Most strategies are slides shown once a year. The real test is simpler: can a team make a decision with it without asking you? Vision and mission say where and why. The strategy says what you do and what you deliberately do not do. Clearly written and openly shared, including the options you rejected, it moves decisions to where the knowledge is, and that is exactly what makes a company fast.

Many team meetings count tickets instead of settling questions. What matters is not who has how much open, but what you need as a company right now to move forward, and what the next step is. Fixed rituals, an agenda everyone shapes, a clock everyone sees and minutes written in front of everyone make alignment focused and binding. And one small trick helps more than you would think: being clear beforehand about what you actually want from a topic.

Continuous Integration is not a set of tools but a discipline: changes stay small, flow continuously into one shared state, and every merge is checked automatically. That discipline becomes more important, not less, now that an assistant produces code faster and in greater volume than a human reads it line by line. The checklist in the article helps you place where you stand, from the classic practices to what AI-assisted coding newly demands.

An MVP is not the stripped-down version of your idea, but the smallest one that answers a real question. AI tools have lowered the hurdle to the first running thing so far that starting small is today not just good advice, but realistically doable in a weekend. The further your product gets, though, the more fields demand attention, from law to design to operations. That is not a setback but a learning journey, and nobody has to carry it alone.

Ask an LLM about your own business figures and it will happily guess, and make up a very plausible story to go with it. The fix is not to throw more data at the model, but to take the arithmetic off its hands: a database delivers the exact figure, the model the language around it. That keeps the raw data confidential and the answers deterministic, and turns rigid dashboards into a conversation with your own numbers.

RSS is a standard from the last millennium, and hardly anyone talks about it any more. Yet it sits inside every podcast and is one of the few ways to subscribe to content without being measured: no account, no cookie, no algorithm. Readers decide what they read with, when, and in which order. And on the side, a feed helps search engines find new content faster.

One of the most persistent myths about cloud costs is that FinOps is, at its core, a question of tooling. It isn't. Runaway costs almost always come down to the same cause: nobody decided up front how much a product is allowed to cost. That is why no tool solves the problem on its own. What does is a clear expectation and a shared data foundation where cost, operations and organisation come together.

You don’t set up a KPI because you can measure something, but because you need visibility into something specific: a number that should improve, or a guard that warns you when a change elsewhere makes something good worse. Everything else is a vanity metric. The purpose dictates the form, a corridor with a target, a risk threshold and an opportunity threshold instead of a bare number, and running a product takes just three of them: allocation, forecast accuracy and efficiency.

At AWS, support is not a fixed fee but a percentage of usage that quietly grows as the bill grows. The overhaul of the support plans at the end of 2025 shifted that calculation: Business Support+ replaces the old Business Support, and the Enterprise minimum drops from USD 15,000 to USD 5,000. That makes the question of which plan fits which account structure interesting again, and the calculator in the article lets you work it through with your own numbers.

A single AWS account feels simple at first, and that is exactly why it is rarely questioned, until a misplaced permission hits production or nobody can tell which cost item is for what. Yet at AWS the account is the strongest isolation boundary, and security, reliability and cost transparency all depend on it, which is why the Well-Architected Framework recommends a deliberate multi-account strategy. For a small product company, a manageable split into management, backup, development, staging and production is enough. It pays off most early on and is most expensive to retrofit later.

When a shop or product site moves, people think about design and content, and rarely about the addresses under which Google knows the old pages. Every old URL that leads nowhere gives away reach that took years to build. Take an inventory of the old addresses first, redirect them properly and actively announce the new structure to Google, and your ranking moves with you.

An undocumented platform that keeps breaking, and next to it the new world is supposed to take shape. Anyone who only fixes each outage meets it again a few weeks later in a slightly different form. What helps is an operations handbook in Markdown in your own Git, where every insight ends up, including those from outages. An AI with read-only access collects data, takes notes and links earlier outages, and people review every change through a pull request. The result is a knowledge base that grows with every outage and makes the next one faster to fix. And the same source yields a report for the tech team and a summary for the CEO, with the real business impact in numbers.

For techies, DNS is the control centre of the internet; for many others it is just “that setting in the router”. Yet practically everything depends on it: whoever redirects the MX record intercepts email and can use it to reset one account after another, and MFA does nothing to stop that. Real security therefore does not sit at the individual login, but in control over DNS and the accounts that hang off it.

A compromised npm package does not become dangerous when it lands in the repository, but the moment a developer installs it locally. Anyone who takes the supply chain seriously should therefore not ask “Did we scan?” but “Can we determine our blast radius within minutes?”, and that is an organisational question, not merely a tooling one.

Security is often treated as a point in time: “We check at release.” Yet most risks do not arise because new code is written, but because what we know about dependencies shipped long ago changes. Security is therefore an attribute of operations, not of the build, and the growing gap between the state of the system and the state of knowledge is exactly what security debt amounts to in practice.

With the German NIS2 implementation act, binding minimum standards for IT security are now law for around 30,000 companies in Germany. The registration deadlines have passed, but those who review and act treat security not as a checkbox but as a quality feature of their own operations. Beyond the tipping point where enough value creation is digital, it becomes a business question anyway.

Security and internal rules are often treated like a document: written once, filed, ticked off. But a policy does not become effective by existing; it becomes effective when its knowledge is within reach at the decisive moment. A real-life reporting odyssey shows how quickly even people who want to help run into a dead end, and why knowledge of internal rules belongs where the work actually happens.

Most rulebooks are well meant and hard to reach, because a policy is written once and then overtaken by the very moments in which it would matter. Protection does not come from the document, though, but from the concrete decision. So the question is not whether the rules exist, but whether they feed into the moment of decision instead of sitting silent in a folder.

A cookie banner is rarely a sign of particular care; more often it signals that a website wants to know more about its visitors than it needs in order to work. The duty to obtain consent does not depend on the technology but on the purpose. If all you want is a good user experience, localStorage serves you better than a cookie, because the data stays in the browser instead of travelling to the server with every request.