The Wavect glossary

A CTPO carries the responsibilities of a CTO and a CPO under one neck. They own what gets built, how it gets built, and whether it actually solves the customer’s problem. The role exists because pre-product-market-fit startups cannot afford two senior hires and cannot afford the politics of a CTO and CPO disagreeing about priority every Tuesday.

Worked example of why the combined role wins early: a two-founder startup keeps shipping features the loudest investor asked for, because the technical co-founder builds whatever the product conversation lands on and nobody owns the sequencing. A CTPO collapses that loop. The same person who decides the checkout redesign matters more than the dashboard also decides how it is architected and whether it can ship in this sprint. There is no handoff, no translation layer, and no Tuesday standoff between two C-suite egos, which is the single biggest source of wasted runway pre-PMF.

In a Wavect engagement, a CTPO is usually fractional, delivered through our fractional co-founder model. One operator joins the cap table or the contract, runs product discovery and technical architecture in the same week, and hands off to a permanent split (CTO + CPO) once the company has the revenue and the org structure to justify both. In Austria that engagement is normally a freier Dienstvertrag, since the deliverable is ongoing judgement, not a fixed work product.

The honest trade-off and the common founder mistake: one person becomes the single point of failure, and founders fall in love with the convenience and keep the CTPO long past the point the role should have split. The mitigation is a CTPO who knows when to stop being one and recruit their replacement; anyone unwilling to fire themselves is the wrong CTPO. The role should split when engineering management becomes a full-time job (usually 8-plus engineers) and product cannot wait for a weekly batch. Before that, splitting just creates a coordination tax. Related: Fractional CTO Austria.

A CTO owns three things: what you build on, how reliably you ship it, and whether the architecture you chose two years ago still serves the business today. They are not just the most senior engineer or a senior tech lead with a fancier title. They are the operator who decides which fires get fought and which get acknowledged-and-deferred, and who carries the technical risk that lands on the board agenda.

At Wavect we distinguish three flavors. A founding CTO sits on the cap table and is in the trenches writing code. A scale-up CTO has 20-plus engineers reporting in and is mostly running engineering through an engineering manager layer. A fractional CTO is brought in to cover the gap when neither of those two profiles is yet justified by revenue.

Worked example of the most common and most expensive mistake: a seed-stage startup raises a round, gets advised to “hire a real CTO”, and recruits an impressive name from a company with 200 engineers. That person has spent five years running org charts and budgets, not writing code, and now lands in a four-person team that needs someone to architect the system and ship it themselves. Six months and a quarter of the runway later, the team has process and slide decks but the product has barely moved. The CV was real; it was the wrong profile for the stage. Match the profile to the stage, not to the logo.

The honest trade-off founders dodge: a founding-shaped CTO who can build will eventually hit a ceiling on the management side, and a scale-up CTO who can manage is wasted (and bored) at four engineers. The role genuinely changes as the company grows, which is why the question is rarely “do we need a CTO” but “which CTO does this stage need”. When the answer is “the decision authority but not yet the full-time cost”, the fractional version covers it. See Fractional CTO Austria for Wavect’s pillar engagement.

A CPO owns the product. Not the design, not the engineering, not the marketing, but the question of what to put in front of customers and in what order. The role exists because every shipping decision is a choice not to ship something else, and at scale that choice needs an owner. Combine it with the CTO remit in one person and you get a CTPO; keep it part-time and you get a fractional CPO.

A good CPO is fluent in three languages: customers (what hurts), engineers (what is possible), and the executive team (what moves the P&L). When one of those three is missing, you get product debt: shipped features no one bought, or revenue features no one shipped.

Worked example of the missing-language failure: a CPO hired straight from a sales-led org is fluent in P&L and customers but cannot read what engineering tells them about cost. They commit the roadmap to a quarter of “quick wins” that are quietly six months of platform work, the dates slip, and trust erodes on both sides. The mirror-image failure is the engineer-turned-CPO who can scope anything but cannot say which feature actually moves revenue. The job is the translation between all three, and weakness in any one shows up as the wrong thing getting built confidently.

The honest trade-off and the common mistake: founders reach for a dedicated CPO too early. Pre-PMF the role is overkill, because the founder’s own customer intuition is the most valuable product asset in the company and cannot be delegated. The work gets absorbed by the founder or a CTPO until the engineering team is large enough that deciding what to build next is a full-time job. Before that point, hiring a CPO mostly adds a layer between the founder and the customer, which is the opposite of what an early-stage product needs. Related: Fractional CTO Austria.

Fractional Co-Founder is Wavect’s flagship service and it is exactly what it sounds like. We embed at the level a co-founder would: product strategy, technical architecture, sprint planning, customer calls, board prep. In role terms it is usually a fractional CTPO, product and technology under one neck. We do not show up with a tracked-hours timesheet. We show up with the outcome.

Pricing is 400 EUR per week, cancel any week, no notice, no exit fee. If we do not blow you away, the last week is refunded. We do this because the wrong fit costs both sides too much. A two-week trial that ends cleanly is a better outcome than a six-month contract that limps.

Worked example of when this is the right shape: a non-technical founder has revenue but keeps hiring agencies that build the wrong thing because nobody on the inside can challenge the brief. A fractional co-founder sits between them and the builders, owns the roadmap, makes the architecture calls, and tells the founder when the feature they are emotionally attached to is the wrong bet. That posture, owner not contractor, is the entire difference from a fractional CTO, which covers technology authority but does not carry the product and ownership weight.

The Austrian legal nuance: this is engaged as a freier Dienstvertrag, not a Werkvertrag, because we owe ongoing judgement and availability rather than one fixed deliverable, and unlike a real co-founder there is no equity grant or cap-table entry by default. The honest trade-off, and where founders get it wrong: this is not a body to grind tickets (hire a contractor for that) and it is not a substitute for the founder’s own conviction. If you need someone to sit on a hard architecture decision with you at 11pm on a Sunday under a clear SoW, this is the shape of engagement you want. Past PMF and looking for a CTO instead? See Fractional CTO Austria.

The market for fractional CTOs exists because hiring a full-time one too early is expensive and hiring one too late is fatal. A fractional CTO bridges the gap: they make the architecture calls, run the hiring loop for senior engineers, sit in on board meetings, and write the technical sections of investor decks.

Worked example: a seed-stage company has two strong mid-level engineers, a founder who can read code but not architect a system, and an investor asking why the roadmap keeps slipping. They do not need a full-time CTO at 180k plus equity. They need someone two days a week to set the architecture, unblock the two engineers, and turn the roadmap into milestones the board can track. That is the textbook fractional CTO mandate, and it usually runs six to twelve months until a full-time hire is justified.

What they do not do, usually, is write production code. If your team needs a strong individual contributor, you want a senior engineer with a CTO sounding-board, not a fractional CTO doing the engineering themselves. We sometimes blur this line at Wavect when the team is small enough that the CTO must still ship; the SoW makes the boundary explicit.

The legal nuance in Austria: a fractional CTO is normally engaged as a Dienstvertrag or a freier Dienstvertrag, not a Werkvertrag, because they owe ongoing judgement and availability, not a single fixed deliverable. That matters for liability and for how the engagement gets booked. Do not let a vendor dress a fractional CTO retainer up as a fixed-scope contract; the obligations are different.

The common founder mistake: confusing a fractional CTO with a fractional co-founder. The CTO covers technology authority. The co-founder posture adds product strategy and ownership behaviour. If you want someone to challenge your roadmap and not just your stack, you want the latter. The honest trade-off with any fractional model is continuity: a part-time executive will never have the context depth of a full-timer, so the engagement only works if the scope is bounded and the handoff is planned from day one.

Watch for vendors selling “fractional CTO” as a renamed account-manager role. A real fractional CTO has decision authority, attends the same meetings a full-time one would, and is named in your board materials.

An interim CTO is a full-time, temporary executive who runs engineering during a transition, usually for 3 to 12 months. The trigger is a vacuum: the previous CTO resigned mid-fundraise, was let go, or the company outgrew them before a succession plan existed. The interim steps in at full capacity, stabilises the org, and hands over to the permanent hire they often help recruit.

The difference to a fractional CTO is commitment shape, not seniority. Fractional means 1 to 3 days a week, ongoing, for a company that needs CTO-level authority without a full-time presence. Interim means five days a week with a planned end date, for a company that has a full-time-sized hole right now. Pick by the size of the hole, not by which title sounds more senior.

Worked example: a scale-up loses its CTO eight weeks before a technical due diligence. Forty engineers, three teams, no deputy. A fractional operator at two days a week cannot absorb that. The org needs someone in every leadership meeting, every escalation, every diligence call, and that is an interim mandate. The mirror case, a seed startup with four engineers and a slipping roadmap, has a two-day-a-week problem. Paying a full-time interim there burns runway on presence nobody needs.

The Austrian legal nuance mirrors the fractional model: an interim CTO is normally engaged as a Dienstvertrag or freier Dienstvertrag, because the deliverable is ongoing judgement and availability, not a fixed work product. The honest trade-off of interim is the cliff: everything the interim learned walks out at handover, so the mandate must include documenting decisions and recruiting the successor. An interim who is vague about their own exit plan is planning to stay, and that is a different, more expensive product.

Wavect’s engagements are fractional by design, 1 to 2 days a week with two founders on every engagement. If you have a true vacuum that needs five days a week, hire interim, and we will tell you exactly that on the first call. Where the two shapes overlap is covered in Fractional CTO Austria.

Less common than the fractional CTO model but increasingly real. A fractional CPO joins for 1 to 3 days a week to run product discovery, sequence the roadmap, and own the customer-interview cadence. They do not own engineering. They do not own design unless you ask them to.

The fit is narrow: the company needs product seniority but cannot yet justify the cost of a full-time CPO, AND the founder is willing to delegate the product call. If the founder is also the product person and is not ready to share that authority, a fractional CPO is a friction generator.

Worked example: a company has hit early traction, the founder is buried in sales, and the engineering team is shipping whatever the loudest customer asked for last week. A fractional CPO comes in to install a prioritisation framework, run a proper discovery cadence, and give engineering a sequenced roadmap instead of a queue of one-off requests. Three days a week is enough because the job is judgement and structure, not execution volume.

The common mistake founders make is hiring a fractional CPO to avoid making product decisions themselves, before PMF. That never works. Pre-PMF, the founder’s intuition for the customer is the company’s single most valuable asset and cannot be outsourced. A fractional CPO scales a product function that already has a point of view; it does not invent one. In Austria the engagement is typically a freier Dienstvertrag, like most fractional executive roles, because the deliverable is ongoing judgement rather than a fixed work product.

The honest trade-off: a part-time CPO will always lag a full-timer on context, and product context compounds. If your roadmap decisions need to be made daily off conversations the CPO was not in, the model breaks. It works when decisions can be batched weekly and the team can execute between sessions.

Related: Fractional CTO Austria.

A tech lead is an individual contributor first and a coordinator second. They write code. They review code. They make the call when two engineers disagree about an implementation. They are not a manager: they do not handle promotions, performance reviews, or hiring loops outside their own team. That last distinction is the one that separates them from an engineering manager, and getting it wrong is expensive.

At Wavect we often deploy a tech lead alongside a fractional CTO. The CTO owns the architecture and the cross-team coordination. The tech lead owns the day-to-day quality of the team’s output: code review standards, how the team practices agile, whether the definition of done is real or theatre. Conflating the two roles is the most common mistake we see in series-A startups.

Worked example of that mistake: a company promotes its best engineer to “tech lead” and then quietly piles on 1:1s, hiring interviews, and headcount planning. Six months later the codebase has drifted because nobody senior is reviewing it, and the new lead is burned out doing two jobs badly. The fix is to name the split explicitly: technical authority stays with the tech lead, people authority moves to an EM, even a fractional one.

The honest trade-off: a strong tech lead with an external CTO sounding-board often outperforms a junior full-time CTO on paper, and costs far less. The ceiling is decision authority outside the team. A tech lead does not own architecture across products or board-level technical risk, and pretending they do just delays the moment you actually need a CTO.

How much should a tech lead actually code? Most of the time, and this is where founders quietly break the role. The instinct, once someone is “the lead”, is to pull them into meetings, planning, and coordination until they are coding ten percent of the week. A tech lead who stops shipping loses the team’s technical respect and drifts from the codebase they are supposed to have the deepest knowledge of. The rule of thumb is at least half their time hands-on, the rest spent on review, design, and unblocking. The day the coordination load genuinely exceeds that, you do not have an overloaded tech lead, you have an unfilled engineering-management seat.

Related: Fractional CTO Austria.

Engineering managers run people, not architecture. They sit between the engineers and the rest of the company: they translate strategy into team-level priorities, they own the hiring loop, they handle the conversations no engineer wants to have. The technical decisions stay with the tech lead; the EM makes sure the people making those decisions are growing, supported, and not about to quit.

A good EM has technical credibility (engineers respect them) without competing with the team’s senior ICs. A bad one is either too disconnected to lead or too in-the-weeds to manage. The role is one of the hardest to hire for; most early-stage startups overhire on the technical side and underhire on the management side, which is why teams of eight start to wobble.

Worked example: a team grows from five to ten engineers in a year. Nobody added management, so the founding CTO is now running ten 1:1s, three hiring loops, and two performance problems while still trying to own architecture. Velocity craters, two people leave, and everyone blames “process”. The actual cause is a missing EM. The signal arrives months before the attrition: the most senior person spends more time in meetings about people than in the codebase or the SDLC.

The common mistake is promoting a strong senior engineer into the role with no training and assuming the people skills will follow the technical ones. They usually do not; the two skill sets are close to independent. Promote for demonstrated interest in the people work, then teach the technical context, not the other way around.

The honest trade-off: a great EM makes the team’s output less legible to the founder, because their best work (retention, unblocking, hard conversations) does not show up on a Gantt chart. Founders who measure only shipped features tend to under-value and under-hire the role until the wobble becomes attrition.

Related: Fractional CTO Austria.

A Product Manager owns the what and the why, not the how. They decide which problem the team solves next, why it matters, and what “done” means for the customer. They do not write the code, they do not run the sprint as a manager, and they do not design the architecture. Their job is to make sure the team is building the right thing before anyone argues about how to build it well.

The role is mostly judgment and communication under conflicting pressure. Sales wants the deal-closing feature. Support wants the bug fixed. The founder wants the bold bet. A good PM holds all of that, says no to most of it out loud, and ships the one thing that moves the business. They are accountable for the outcome, which means they own the roadmap and the prioritisation calls, not just the backlog grooming.

Product Manager versus Product Owner is where most teams get confused. Product Owner is a specific Scrum role, distinct from the Scrum Master: it owns and orders the backlog so the development team has a clear next thing to build. Product Manager is the broader business role: market, strategy, pricing input, stakeholder alignment, and the why behind the roadmap. It is the seat that scales up into a CPO (or a fractional CPO) once the org is large enough. On a small team one person wears both hats. On a larger one the PM sets direction and the PO turns it into ordered, ready-to-build work.

The common mis-hire is a PM with no authority. If the roadmap is really set by the loudest stakeholder and the PM just writes tickets, you have hired a project coordinator and called it product. We slot product ownership into founding teams as part of a fractional co-founder engagement when the founder is too deep in the build to own it.

A Software Architect owns the decisions that are hard to undo. How the system is split into services or modules, how data flows through it, where the boundaries sit, which technologies the stack commits to, and how the whole thing holds up under load, failure, and growth. Individual features are cheap to change. These structural choices are not, which is why they need someone thinking at the system level rather than the feature level.

The real value is in the non-functional requirements: performance, scalability, security, reliability, maintainability. These are the things no single feature ticket owns and that quietly sink a product when ignored. The architect’s job is to name the trade-offs out loud. Faster to build now versus cheaper to change later. Simple and limited versus flexible and complex. There is no free architecture, only trade-offs you chose on purpose or trade-offs you inherited by accident.

Most startups do not need a dedicated Software Architect, and hiring one early is usually a mistake. At small scale the architecture is small, and the tech lead or CTO carries it as part of their job. A full-time architect with no code to write and no team to lead tends to produce diagrams and standards documents that the team then ignores. The role earns its keep once the system is large enough that nobody holds the whole picture in their head.

Worked example of why the no-code architect drifts wrong: an architect who left the codebase two years ago designs a “clean” event-driven system with six queues and three databases, because on a whiteboard that decouples everything nicely. The team that has to build it discovers the local development setup now takes a day to stand up, every feature touches four services, and debugging a single user complaint means correlating logs across all of them. The diagram was elegant; the lived experience is misery. An architect still close to the code would have felt that cost coming, because they would have been the one running the six queues on their laptop.

The honest take: “Solutions Architect” on a vendor’s org chart often means a pre-sales role that designs systems they will never have to maintain. A good architect stays close enough to the code to feel the consequences of their own decisions. If the person drawing the boxes never has to live inside them, the boxes will be wrong.

A Scrum Master has one real job: make the team more effective by getting things out of its way. That means removing blockers, shielding the team from mid-sprint interruptions, facilitating the Scrum standups and retros so they are useful instead of theatre, and coaching the team on how to actually work, not just recite the ceremonies. They are a servant to the team, not a boss over it. They do not assign work, they do not own the backlog (that is the product manager or product owner), and they do not do performance reviews (that is the engineering manager).

The role gets misunderstood in two directions. Some treat it as a glorified meeting scheduler who reads the standup script. Others quietly turn it into a project manager who pushes the team to commit to dates. Both miss the point. The value is in spotting what is slowing the team down, often something organisational and uncomfortable, and having the standing to fix it. A Scrum Master who only runs meetings is overhead.

Here is the honest take: small teams rarely need a full-time Scrum Master. A team of four or five engineers can run its own ceremonies, and the facilitation work is a few hours a week that a tech lead or senior engineer can absorb. A dedicated full-time Scrum Master earns the seat when you are coordinating multiple teams, when the organisation around the team is the main source of blockers, or when a team genuinely cannot self-organise yet. Below that, the title is a cost looking for a justification.

We have seen plenty of teams happier and faster after dropping the full-time Scrum Master and folding the work into the team. We have also seen teams drown because nobody owned the blockers. The role is real, the full-time version is often not.

CTO as a Service is a packaging label, not a different job. Under the label, a vendor sells CTO-level judgement (architecture calls, hiring loops, vendor management, board-ready reporting) as a recurring service with a defined time commitment. Strip the branding and what remains is a fractional CTO on a retainer: same authority, same meetings, a subscription instead of a salary.

The label matters because of what it can hide. “As a service” implies the person is swappable, and CTO work is the least swappable work a company buys. Context compounds: the architecture decision made in month one only makes sense to the person who watched the trade-offs land in month four. Vendors that rotate consultants behind a service brand reset that context every rotation, and the client pays for the re-onboarding every time.

Worked example of the failure mode: a startup signs a CTO-as-a-Service package with an agency. The first month is a senior architect. By month three, the weekly call is run by an account manager who relays questions to a pool. The startup still pays executive rates, but no one in the room can say no to a feature without checking upstream. That is account management with a CTO sticker, and it is the single most common complaint that brings founders to us from this category.

What to check before signing: who exactly shows up (named people, not a pool), whether they hold decision authority or escalate to someone you never meet, and how the engagement ends (a handover plan, not a renewal pitch). In Austria this is normally a Dienstvertrag-style retainer rather than a Werkvertrag, because the deliverable is ongoing judgement, and a clean weekly or monthly cancellation clause is the honest version of “as a service”.

Wavect’s version is the Fractional CTO Austria engagement: CTO-on-Call from EUR 2,500 per month or an embedded operator at 1 to 2 days a week, two named founders on every engagement, cancel any week.

A Statement of Work is the document that turns a verbal agreement into a contract. It lists the deliverable in concrete terms (“feature X live on production, passing acceptance criteria A, B, C”), the price, the deadline, and the conditions for sign-off.

In Austrian and German law the corresponding instrument is the Werkvertrag, which is stronger than the English-language SoW: the vendor is legally bound to deliver the work, not just to provide effort, and the customer can withhold payment until the work is accepted. A Time & Material contract under the same legal framework is a Dienstvertrag, which only obliges effort. Wavect’s fixed-price engagements are Werkvertrag contracts.

Worked example of why the acceptance criteria carry the whole contract: an SoW that says “build the reporting feature, the feature should work well” is unenforceable, because “work well” is an opinion. An SoW that says “endpoint /reports returns the monthly figures for input range R within 200ms under load L, matching values in spec S” is testable, and “done” is no longer a negotiation. The most common founder mistake is signing a vaguely worded SoW to save time at the start, then spending six months arguing about whether a half-working feature counts as delivered. A vendor who resists writing precise acceptance criteria is protecting their right to have that argument later.

The SoW is also the document that prevents scope creep: anything not in it is by definition out of scope and gets handled with a change request. Note the layering, an MSA (Master Services Agreement) covers the legal frame (IP, liability, jurisdiction) once, and many SoWs live under it over time. The honest trade-off is that a tight SoW takes real work to write and feels slow up front, which is exactly the work a paid discovery-phase exists to do. Related: Fractional CTO Austria explains the Werkvertrag model in practice.

Time & Material is the default engagement model for staffing agencies and most freelance contracts. You pay an hourly or daily rate; the vendor logs hours; the bill arrives monthly. There is no contractual deliverable, only contractual effort. In Austrian and German law this maps to a Dienstvertrag: the vendor owes effort and diligence, not a finished work product. That legal distinction is the whole game, and it is why a Statement of Work (a Werkvertrag) is a fundamentally different instrument, not just a different invoicing style.

The model is honest in the sense that nobody pretends the vendor owns the outcome. It is also the worst-aligned of the common engagement models: the vendor’s incentive is to bill more hours, not to finish faster. Smart customers cap T&M engagements with a budget ceiling and a clear scope, which is essentially reinventing a fixed-price engagement without the legal teeth.

Worked example of how T&M goes wrong: a founder signs a “T&M to keep things flexible” contract for a feature everyone already agreed on. Three months and 40k later it is 70% done, the agency proposes another six weeks, and the founder has no contractual lever to pull because they never named a deliverable. Had the same work been scoped as a Werkvertrag, the 70%-done problem would have been the vendor’s to solve at the vendor’s cost.

Wavect uses T&M for exploratory engagements where the scope genuinely cannot be defined upfront. We do not use it as a default. The honest trade-off is real: T&M is genuinely the right model for open-ended research or unpredictable maintenance, where forcing a fixed scope would just make us pad the estimate or argue about “done”. The rule of thumb: use T&M when nobody can yet describe the deliverable, and switch to a retainer or an SoW the moment they can. If a vendor pushes you toward T&M for work that has a clear deliverable, they are pushing the risk onto you.

A fixed-price engagement transfers delivery risk from the customer to the vendor. The price is fixed before work starts. The scope is named in writing. The deadline is part of the contract. If the vendor goes over budget or over schedule, that is the vendor’s problem, not yours.

For this to be real and not theatre, the contract has to be a Werkvertrag (under AT/DE law) or its closest local equivalent. A Werkvertrag legally binds the vendor to deliver the work, not merely to provide effort, and the customer can withhold payment until the work is accepted. “Fixed price” as a verbal promise with a Time & Material contract underneath is not a fixed price; it is a marketing line. The underlying SoW is where the guarantee actually lives or dies.

Worked example: a vendor quotes “around 25k, fixed” but the SoW says “payment monthly against hours” and lists no acceptance criteria. That is T&M wearing a fixed-price hat. The honest version names the deliverable (“checkout flow live, passing acceptance tests A, B, C, by date X”), states the price, and puts the overrun risk on the vendor. If they will not write that down, the price is not fixed.

Wavect runs fixed-price for engagements where the scope is well-defined and the discovery work has already happened. For pre-discovery work we run a 2 to 3 week Discovery Phase first, which itself is fixed-price. The cost gets deducted from the build invoice if you continue with us.

The honest trade-off, and the most common founder mistake: forcing fixed-price onto genuinely uncertain scope. When the unknowns are large, a fixed-price vendor either pads the estimate by 30 to 100% to absorb the risk, or underbids and then cuts quality to stay in budget. Neither serves you. Do discovery first, fix the price on what you actually know, and keep the genuinely unknown parts on a different model. Wavect’s fixed-price guarantee means signed SoW (Werkvertrag), legally bound to deliver. It does not mean refund-if-we-miss-the-deadline.

Related: Fractional CTO Austria publishes fixed prices per tier.

A retainer is a subscription to a vendor’s time. You pay every month; in return you get a defined number of days or a defined team capacity. The exact scope shifts; the availability does not.

Retainers work well when the work is ongoing and the priorities change too fast for a Statement of Work to keep up. Product teams use retainers for design partners, engineering teams use them for fractional senior roles, and almost every legal counsel arrangement is a retainer. In Austria a retainer is usually structured as a Dienstvertrag or freier Dienstvertrag, since what you are buying is reserved availability and judgement rather than a fixed work product.

The risk is the inverse of T&M: the vendor gets paid even when there is no work. Smart customers attach a “reasonable use” clause and review the retainer quarterly to confirm capacity is being used. If utilisation is below 60%, the retainer is the wrong shape and you want a per-engagement SoW instead.

Worked example: a startup puts a senior advisor on a 10-day-a-month retainer “to be safe”. For two months it is fully used; then the launch ships and the work drops to two days a month, but the invoice does not. They are now paying for eight idle days. The fix is not to cancel the relationship, it is to right-size it: drop to a smaller retainer plus the option to scope a fixed-price build when a real deliverable appears. Healthy retainers sit at 70 to 85% utilisation; below that you are buying insurance, above 95% you are running the vendor as staff with no slack for the work that matters.

The honest trade-off is predictability versus efficiency. A retainer buys you a known monthly cost and a reserved senior brain, at the price of paying for capacity in the quiet months. Related: Fractional CTO Austria runs a weekly retainer you can cancel any week, which removes most of the lock-in that makes traditional retainers risky.

Discovery is the work that has to happen before a fixed-price build can be quoted honestly. It produces four artifacts: a software architecture, a milestone plan, the critical technical flows, and a launch plan. From those, the vendor can quote a real fixed price and write a defensible SoW.

Wavect runs discovery as a 2 to 3 week fixed-price engagement at 3,500 EUR. If you continue with us for the build, the discovery fee is deducted from the first invoice. If you do not, you keep all four artifacts and can take them to another vendor. That last point is the test of an honest discovery: the output should be useful even if you walk away.

Worked example of why this matters: a founder collects three “free” quotes for the same app and gets 30k, 70k, and 110k. The spread is not vendor greed, it is that none of them actually scoped the work, so each padded for a different set of imagined unknowns. A paid discovery collapses that spread by replacing guesses with an architecture and a milestone plan, which is also what an honest SDLC starts from. The same artifacts let you tell the difference between an MVP you can ship in eight weeks and a platform you are quietly committing to for a year.

The reason we charge for discovery: free scoping work is either dishonest (the vendor recovers the cost in the build estimate) or low-quality (the vendor rushes it because it is not paid). Charging fixes the incentive. The honest trade-off is that discovery feels like spending money before you have anything to show. You do have something: the four artifacts are a portable asset, and the alternative (committing six figures to a build nobody scoped) is the expensive option, not the cheap one.

Related: Fractional CTO Austria lists Discovery as one of four pricing tiers.

Sprint is a Scrum-specific term that has leaked into general usage to mean any short, time-boxed unit of work. The original definition requires three things: a fixed length, a planning session at the start, and a review at the end. Most teams keep the first two and drop the third, which is why a lot of teams call their cadence “sprints” but produce no demonstrable increment. A sprint without a demo is just a deadline; a sprint without a retro is a treadmill.

The duration matters. One-week sprints force tight scope and surface delivery problems fast. Two-week sprints give more room for substantial work but absorb more drift. Three-week sprints almost always become two badly-planned ones.

Worked example of the silent failure: a team runs two-week “sprints” for six months, hits every planning meeting, and ships nothing a stakeholder can click on. The board keeps slipping because work is sized by hope, not by what fits, and there is no review forcing the team to confront a working increment. The fix is brutal and simple: at the end of every sprint, someone outside the team has to be able to use what was built. If they cannot, the cadence is theatre, and shrinking to one-week sprints usually exposes why within a fortnight.

The honest trade-off and the most common founder mistake: treating sprints as a way to hit a fixed external deadline. The cadence is built around fixing the time-box and flexing the scope, which is the opposite of a hard launch date with fixed scope. For genuinely date-driven, fixed-scope work you want a fixed-price plan with explicit SDLC milestones, not a sprint board. Sprints fit ongoing agile delivery and iterative work toward an MVP; they fit research and design work poorly, where a time-boxed exploration with a written summary beats a forced demo. They also depend on CI/CD being healthy, because a sprint that cannot ship at its end is not a sprint.

Staff augmentation adds external engineers to your existing team. They report into your standups, work your backlog, and follow your processes. You keep the management, the architecture decisions, and the accountability. The vendor supplies bodies and bills for time. That is the whole model.

It fits when you have a working team and a working plan, and you simply need more hands at the keyboard for a known stretch of work. It is almost always billed time-and-material, so the delivery risk sits with you. It does not fit when you do not yet know what to build, when nobody internal can direct the new engineers, or when you need someone to own an outcome rather than execute a ticket. For ownership you want a dedicated team or a fractional senior role, not augmentation.

The seniority trap is the part nobody puts in the brochure. Most augmentation shops advertise senior profiles and staff you with juniors who need the same hand-holding your own juniors would, except now you are paying agency rates for the privilege. You carry the management overhead and the vendor carries none of the delivery risk. Read the named CVs, interview the actual person, and put a swap clause in the contract.

There is an Austrian legal wrinkle worth flagging: staff augmentation can shade into Arbeitskräfteüberlassung (labour leasing), which is a regulated arrangement with its own obligations around who directs the worker and how they are treated. If an “augmented” engineer is fully embedded under your direction for an extended period, the relationship may legally look more like leased labour than a service contract, with consequences for both sides. It is rarely a problem for short, well-scoped engagements, but it is worth getting the contract shape right rather than discovering the classification during an audit.

Wavect does not run a body shop. We are senior-only operators, so when we sit inside your team it is the person on the software development page doing the work, not a name on a roster who gets quietly substituted in week three.

Technical due diligence is what a serious investor or acquirer commissions before money changes hands. It answers one blunt question: does the technology actually support the valuation, or is the story better than the codebase. A proper review covers code quality and maintainability, the architecture and whether it scales past the next order of magnitude, the security posture, the state of the test suite and delivery pipeline, the team’s real depth, and the key-person risk that sits in one founder’s head.

For the buy side, tech DD is risk pricing. You are not looking for perfect code; every company at this stage has debt and a rough SDLC. You are looking for the gap between what the deck claims and what the repository shows, and for the landmines that turn into post-close emergencies: a single engineer who knows how everything works, a license that poisons a commercial product, a compliance hole, an architecture that cannot survive the growth you are paying for.

For the sell side, getting your own tech DD done before the room does it for you is one of the cheapest ways to protect a valuation. Surprises during diligence cost you leverage; findings you already understand and have a plan for do not. Founders who run a pre-emptive review walk into the data room with answers instead of explanations.

Worked example of the single finding that moves a deal: a buyer’s reviewer discovers that the entire payments and reconciliation core was written by one engineer who left eight months ago, is undocumented, and has no tests. That is not a code-quality footnote; it is key-person risk that the acquirer will price as a discount or a holdback, because the day something breaks in that module, nobody currently at the company can fix it confidently. A founder who ran their own review would have seen this coming and either documented the module, paid for a second engineer to learn it, or at least walked into the room with a credible remediation plan. The same finding, surfaced by the buyer instead of by you, costs real money on the term sheet.

Wavect runs technical due diligence as a senior operator, not a checklist auditor, the same posture we bring to a paid discovery-phase. We have done it on both sides of the table, including data-heavy and regulated platforms, and we write findings a non-technical board can act on. It pairs naturally with our fractional co-founder work and fractional CTO mandates, where the same person who assesses the risk can help fix it.

A proof of concept exists to retire one specific technical risk. Can this model hit the latency we need. Will this integration actually work against the legacy system. Can we prove the cryptography before we design a product around it. A PoC answers "is this possible" and nothing else. It is built fast, judged on whether it works, and then thrown away.

The distinction that costs companies the most is PoC versus MVP versus prototype. A PoC answers “is this technically possible” and is aimed at your own team. A prototype answers “does this feel right” and is aimed at design and usability, often with no real backend at all. An MVP answers “will anyone actually use and pay for this” and is a real product, shipped to real users, just scoped to the smallest version worth their time. They have different audiences, different quality bars, and different definitions of done, and the difference maps directly onto where you are relative to PMF.

The common and expensive mistake is shipping a PoC as if it were production. The code that proved a thing was possible was written to prove a thing was possible: no error handling, no tests, no security review, shortcuts everywhere. When the demo impresses someone and the decision is made to “just ship it,” you inherit all of that as your foundation. The honest move is to treat the PoC as the answer to a question, then build the real thing properly.

One way to make that discipline hold under pressure: write down the single question the PoC exists to answer before you start, and the criteria for a yes or a no. “Can this model classify support tickets at 90% accuracy on our last 500 tickets” is a question with a clear verdict. Without that written question, a PoC quietly mutates into a half-product, the team keeps polishing it because it “almost works”, and you have slid into building V1 on disposable foundations without anyone deciding to. The written question is also what protects you from the sunk-cost pull to ship the throwaway code: once the question is answered, the PoC has done its job and earned its deletion, no matter how nice the demo looked.

Wavect runs a PoC when there is genuine technical risk worth retiring before committing to a build. Most projects do not need one; they need a discovery-phase that scopes the work. We will tell you which one you are looking at.

A dedicated team is an external squad assigned to your product, with its own technical lead, owning a workstream from planning through delivery. Unlike staff augmentation, you are not managing individual engineers ticket by ticket. You set the direction and the priorities; the team’s lead handles the day-to-day execution, the internal coordination, and the delivery. The vendor owns the outcome, not just the time spent reaching it, which is why it is usually priced as a monthly capacity fee or retainer rather than billed by the hour.

It fits when you have a whole problem to hand off rather than a gap to fill: a product line, a platform, a workstream that can run with a clear interface to the rest of your organisation. It fits when you do not have the internal management bandwidth to direct individual contractors, because the team manages itself. It does not fit when the work is deeply entangled with your existing team’s daily decisions; that entanglement is exactly what staff augmentation is for.

The honest trade-off is the interface. A dedicated team reduces your management overhead per engineer but introduces a coordination boundary between two groups working on one product. That boundary costs you whenever priorities shift fast or context needs to flow constantly across it. The teams that make dedicated work well invest in a single clear point of contact, a shared definition of done, and enough overlapping hours to keep the boundary thin.

The failure mode to watch for is the dedicated team that is dedicated in name only, quietly time-sliced across three other clients. You are paying for reserved capacity and an owned outcome; if the same engineers are context-switching between your product and two others, you get neither the ownership nor the focus, just augmentation with a markup. Ask who specifically is on the team, whether they are full-time on your workstream, and what happens to continuity if one of them rolls off. A real dedicated team has stable membership and a named lead who carries the context; a fake one has a rotating cast and a project manager forwarding your messages.

Wavect keeps teams small and senior, so the team that owns your workstream is operators who can make decisions, not a layer of juniors with a project manager in front. See the software development page for how we structure delivery.

Nearshoring means outsourcing development to a vendor in a nearby country, usually within a couple of time zones. For DACH companies that typically means Eastern Europe rather than South or Southeast Asia. Onshore is a vendor in your own country at your own rates. Offshore is the far end: lowest day rates, largest time-zone gap, longest communication chain. Nearshore sits in the middle and is sold as the sweet spot: cheaper than onshore, easier to work with than offshore.

The advertised number is the day rate, and on the day rate nearshore wins. The number nobody puts on the proposal is the coordination tax: the hours lost to time-zone overlap that is shorter than it looks, the rework caused by specs that travel badly across a language and culture gap, the senior time on your own side spent reviewing, correcting, and re-explaining. A cheaper engineer who needs twice the direction and produces work you have to redo is not cheaper. The cheap-rate math breaks the moment the work needs tight collaboration rather than well-specified, self-contained tasks.

Nearshore can be the right call. For well-bounded, clearly specified work where the requirements are stable and the interface to your team is thin, the rate saving is real and the coordination tax is small, and the engagement usually takes the shape of staff augmentation or a dedicated team. It breaks down for ambiguous, fast-changing, or deeply collaborative work, which is precisely the work most early-stage and product-led companies are actually doing. Be honest about which kind you have before you optimise for the day rate.

Wavect is a DACH consultancy: same time zone, same language for the conversations that matter, senior people who need direction once rather than three times. When you compare us against the nearshore rate, compare the all-in cost including the coordination tax, not the line on the invoice. See software development for how we work.

Web3 names a family of technologies, not a single thing. The shared property is that user state (assets, identity, sometimes data) lives on a public blockchain instead of in a centralised database. The user signs transactions with a private key they hold. The vendor cannot freeze or delete their account.

In practice the term covers wallets, smart contracts, decentralised exchanges, NFTs, DAOs, account abstraction, ZK-based systems, cross-chain bridges, and the application layer that sits on all of the above. Wavect builds in this space across EVM (Ethereum and its compatible chains), Solana, Cosmos, Polkadot, Near, Ton, and ICP.

Worked example of the decision: a founder wants a loyalty-points app and a pitch deck told them to put it “on-chain”. Apply three tests. Do the points need to survive the company going bankrupt? Do multiple parties who do not trust each other need to share the ledger without a central operator? Do they need permissionless composability with other on-chain systems? For a single-company loyalty scheme the answer is no, no, and no, so the right tool is a database, and putting it on a blockchain just adds gas costs, key-management support tickets, and a regulatory headache. Flip one answer to yes (say, points redeemable across competing merchants) and the calculus changes.

The Austrian and EU nuance founders underestimate: a token that looks like a payment instrument or a security drags MiCA, prospectus rules, and tax treatment into scope. “Decentralised” does not exempt you, and the legal cost of getting the token classification wrong dwarfs the engineering cost of the contract. Scope that before you write the smart contract, not after.

The honest version: most Web3 projects do not need a blockchain. The ones that do (assets that must survive the vendor’s bankruptcy, multi-party trust without a central operator, permissionless composability) are valuable. The rest are venture-funded distractions. The trade-off is permanence cuts both ways: the same immutability that makes web3 trustworthy means a shipped bug is a bug forever and value is at stake from minute one. We will tell you which category you fall into.

A zero-knowledge proof lets one party (the prover) convince another (the verifier) that they know some piece of information, without disclosing the information itself. The canonical example: prove that you are over 18 without revealing your date of birth.

In production, ZK shows up in two flavors. ZK-SNARKs are smaller and faster to verify but require a trusted setup. ZK-STARKs are larger and slower but need no trusted setup and are post-quantum safe. Most chains now offer pre-built circuits for common proofs (identity, balance, voting eligibility) so you do not need a cryptographer on staff to ship a smart contract that verifies them.

Worked example where ZK earns its keep: a regulated exchange has to prove to an auditor that every user passed KYC, without handing the auditor a database of names and passport numbers. A zero-knowledge proof lets the exchange attest “this set of accounts is fully KYC-verified” while the underlying identities stay private. In the EU, where GDPR makes that passport database a liability you would rather not hold, the privacy is not a nice-to-have, it is the point. The counter-example is just as instructive: if a trusted database query would satisfy the verifier, ZK is expensive theatre.

The honest engineering trade-off, and the most common founder mistake: assuming the hard part is the cryptography. The math is sound. The risk lives in the circuit. A subtly wrong circuit produces a proof that verifies perfectly while proving the wrong statement, and that bug is invisible until someone exploits it. This is why ZK work belongs near account abstraction and other on-chain primitives where audits are non-negotiable, not bolted on as a marketing feature. The business case is narrower than the hype: ZK is genuinely valuable when you need to prove a property on-chain (or to a counterparty) without leaking the data. It is overkill for most consumer apps and most web3 projects that name-drop it.

In a standard EVM chain, every account is either an Externally Owned Account (a private key) or a smart contract. ERC-4337 introduces a third class: a smart-contract account that the user transacts as. Because the account is a contract, it can hold logic. That logic can sponsor gas, recover from a lost key via guardians, batch multiple calls into one transaction, or enforce custom auth rules like a daily spending cap.

The user experience implications are large. With AA, an end user can sign up with an email and a passkey instead of a seed phrase. Gas fees can be paid by the application or in the application’s token, not in ETH. The wallet can rate-limit suspicious transactions. The trade-off is increased on-chain complexity and higher gas cost per transaction.

Worked example: a consumer payments app wants non-crypto-native users. Without AA, onboarding means “write down these twelve words, lose them and your money is gone forever”, which kills the funnel. With AA, the user signs up with a passkey, the app sponsors the first transactions so they never see a gas fee, and a lost device recovers through guardians instead of a seed phrase. The same pattern lets the wallet enforce a daily spend cap on-chain, which is the kind of guarantee a centralised app could never make credibly.

The common founder mistake is treating AA as a checkbox. It changes the security model: social recovery removes the seed-phrase footgun for normal users but introduces guardian compromise as a new attack class, which is strictly worse for power users who would rather hold the key themselves. The honest trade-off is that AA buys mainstream UX at the cost of more contract code to audit and more gas per action. Wavect has shipped account-abstraction wallets and Snaps (MetaMask plugins) to production. The technology is real and increasingly mainstream. The implementation is non-trivial. If a vendor quotes AA as a cheap add-on, ask which infrastructure they are using and which security audits the contract code has been through. The same audit discipline that applies to zero-knowledge circuits applies here.

An AI agent is the loop, not the model. The model (Claude, GPT, Gemini, an open-weights LLM) is the decision-maker. The agent is the runtime: it gives the model a goal, lets it call tools (a database, an API, a code interpreter, another agent) often via MCP, observes the result, and feeds the loop until done.

The distinction matters because agentic systems fail differently from straight LLM applications. A chatbot can be wrong and the user moves on. An agent that is wrong sends an email, makes a transaction, or deletes a file. Production agents need authorisation gates, observability, and circuit breakers that most prototypes skip.

Worked example of the most common production failure: a support agent is given a “resolve ticket” goal and a set of tools. A malformed ticket sends it into a loop where it calls the same lookup tool dozens of times, burns through the model budget in an afternoon, and never reaches a resolution. The fix is not a smarter prompt, it is engineering: a hard step limit, a cost ceiling, and a circuit breaker that halts the loop and escalates to a human. Anything that writes (sends a message, makes a payment, deletes a record) gets a human-in-the-loop gate; read-only loops can usually run unattended.

The honest trade-off and the founder mistake to avoid: agents add non-determinism, latency, and a much larger blast radius than a fixed pipeline, in exchange for handling tasks whose steps cannot be enumerated in advance. Most workflows pitched as “agentic” are well-understood and are better served by a deterministic pipeline with one or two LLM calls in the middle, often backed by RAG for grounding. Wavect’s posture: start by asking if AI is the right tool here, then whether an agent is the right shape of AI for it. If you can write the steps down, do not let the model improvise them.

Model Context Protocol (MCP) is to AI agents what HTTP is to the web: a shared, open standard for how the model talks to the rest of the world. It was introduced by Anthropic in late 2024 and adopted broadly in 2025 and 2026.

The technical shape: an MCP server exposes resources, tools, and prompts via a defined schema. Any MCP-capable client (Claude Desktop, Claude Code, the API, an IDE plugin) can discover and call those tools without per-vendor glue. Build the integration once; every MCP client benefits.

Worked example of the leverage: a company wraps its internal CRM, its analytics warehouse, and its document store as three MCP servers. This quarter the team is on Claude; next quarter they trial a different model for cost reasons. With function-calling tied to one vendor, that switch means rewriting every integration. With MCP, they point the new client at the same three servers and move on. The integration cost was paid once, not per model. Pairing those servers with RAG over the document store gets you grounded answers from internal data without bespoke plumbing.

The honest trade-off and the founder mistake: MCP is the right call only if you expect to swap models or want portability; if you are permanently on one provider, plain function-calling is simpler and fine. The bigger risk is security. MCP is a transport protocol, not a permission model. A sloppy MCP server that exposes a write-capable tool with weak auth is a confused-deputy waiting to happen, where the model is tricked into invoking something it should not. We build MCP servers regularly and have shipped them to production; we also write a security review for each one because the standard is still moving and the failure mode is your internal systems, not a chatbot saying something dumb. We wrap a tool in MCP only when it is genuinely useful inside a model loop and the security model permits a model to invoke it, with human-in-the-loop on anything destructive.

RAG is the architecture that lets an LLM answer questions about data it was not trained on. The mechanism is straightforward: take the user’s question, retrieve the most relevant chunks from your corpus (via vector search, keyword search, or a hybrid), stuff them into the prompt, and let the model answer. It is the grounding layer underneath most useful AI agents.

The reason RAG exists: training a model on your private data is expensive, slow, and obsolete the moment your data changes. RAG sidesteps that by treating the data as runtime context. The trade-off is that retrieval quality becomes the bottleneck: a model with bad context produces confidently wrong answers.

Worked example of the classic failure: a company builds a support bot over its help docs, the demo is impressive, and then in production it confidently cites the wrong refund policy. The instinct is to blame the model and try a bigger one. The answers stay wrong, because the problem is upstream: the docs were chunked mid-sentence, the embeddings cannot tell “refund” from “return”, and there is no reranker to push the right passage to the top. Swap in better chunking, hybrid search, and a reranker and the same model suddenly looks smart. The lesson generalises: when RAG is wrong, suspect retrieval before generation almost every time.

The honest trade-off and where RAG breaks down: it excels at lookup-shaped questions answerable from a few passages, and degrades when the answer requires synthesising across many documents or reconciling contradictions in the corpus. At that point you want a smaller curated corpus, an agentic pipeline that reasons in steps, or fine-tuning, not a bigger retriever. The unsexy truth is that 80% of the work is making retrieval good (chunking, embeddings, reranking, hybrid search) and 20% is the model. Wrapping your data sources as MCP servers makes the retrieval layer portable, but it does not make it good. Vendors that pitch RAG as a one-click feature are pitching the easy part.

A smart contract is a program deployed to a blockchain. Once deployed, its bytecode is immutable, its state is publicly readable, and its execution is governed by consensus rules that nobody can override. That permanence is the feature and the risk: a bug in production is a bug forever, unless you built upgrade machinery in (which itself is a vulnerability surface).

Most production smart-contract systems are not a single contract but a set of them: a proxy for upgradeability, an implementation contract for the logic, often an access-control contract for governance. The pattern is familiar to anyone who has built versioned APIs; the cost of getting it wrong is higher.

Worked example of why the deployment discipline differs from normal software: ship a bug in a SaaS backend and you patch it and redeploy in an hour. Ship a reentrancy bug in a contract holding user funds and an attacker can drain it before you can react, because there is no rollback and the value is live from block one. This is why the question is not “should we audit” but “how do we structure upgrades safely”. The usual answer is a proxy pattern behind a timelock and a multisig: immediate upgrade authority is a single point of failure, no upgrade path leaves you stuck with the first bug, and timelocked upgrades transparent to users is the middle ground most production systems converge on.

The honest trade-off and common founder mistake: founders treat the contract like a feature and the audit like an optional line item. For any contract holding non-trivial value, the audit is the cheapest insurance you will ever buy, usually 1 to 2 weeks of the build budget against the entire value at stake. Wavect writes smart contracts in Solidity for EVM chains and Rust for Solana, Near, and ICP, and the language is downstream of which chain your web3 use case demands, not a preference. We recommend a third-party audit before mainnet on anything that matters, and we have shipped audited contracts to production. Skipping the audit is how teams learn this the expensive way.

The EVM is the execution layer Ethereum invented and that became the de-facto standard for smart-contract chains. A contract compiled to EVM bytecode runs on Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche C-chain, and a long tail of L2s and sidechains.

The practical implication: write your contracts in Solidity (or Vyper), test on Ethereum testnets, and deploy to whichever EVM chain matches your cost and latency target. The portability is real. The trade-offs between chains are speed, finality, decentralisation, and which L2 framework they are built on.

Worked example of choosing a chain: a DeFi protocol that needs to compose with existing lending and DEX contracts belongs on Ethereum mainnet or a major L2, where that ecosystem lives, even at higher gas. A high-volume consumer app where users will not tolerate dollar-scale fees belongs on an L2 like Arbitrum, Optimism, or Base (same security model, a tenth to a hundredth the cost) or off the EVM entirely toward Solana. The decision is the security-versus-cost trade-off, not whichever chain has the loudest marketing this quarter.

The honest trade-off and the mistake that catches teams repeatedly: EVM-compatible is not the same as Ethereum-equivalent. Subtle differences in gas pricing, precompiles, opcode support, and consensus behaviour mean a contract that passes on mainnet can break on a sidechain. The portability is a starting point, not a guarantee; always re-test per chain before deploying. Account-level UX features like account abstraction also vary in maturity across chains, so confirm support before you promise it.

The deeper trade-off is what you give up for cheap fees. Moving off mainnet onto a cheaper EVM chain almost always means inheriting a different trust model: a sidechain like Polygon PoS runs its own validator set rather than borrowing Ethereum’s security, and a rollup adds a sequencer you now depend on and a withdrawal delay back to L1. None of that shows up in the gas-fee comparison a vendor puts in the deck. Decide what your application actually needs to guarantee before you optimise for the per-transaction cost. For web3 builds we default to Solidity over Vyper for the broader tooling and auditor familiarity, unless there is a strong reason to swim against the current.

Solana is not EVM-compatible. Smart contracts (called “programs” on Solana) are written in Rust, deployed as BPF bytecode, and executed by the Solana runtime. The architecture optimises for throughput (thousands of TPS) and low fees, at the cost of higher hardware requirements for validators and a different (some say more centralised) decentralisation profile.

For consumer applications where the user pays sub-cent fees and confirmation is sub-second, Solana is hard to beat. For deep DeFi composability with the EVM ecosystem, the lift to bridge across is non-trivial. The right chain depends on which trade-off matters more for your product.

Worked example of the gotcha that bites EVM teams: Solana’s programming model is account-based, not contract-state-based. You pass every account a transaction touches explicitly, you manage rent on accounts, and you think about parallel execution from the start. A team fluent in Solidity will routinely under-estimate this ramp-up, ship code that works in the happy path, and then hit edge cases around account ownership and rent that have no Ethereum analogue. Budget real time for the model shift; it is not a syntax translation.

The honest trade-off, and the founder mistake of “pick the fast cheap chain”: Solana’s validator hardware requirements are higher than Ethereum’s, so the validator set is smaller, and historically there have been network outages (fewer recently). For consumer payments and high-volume apps that trade-off is usually fine and the throughput is worth it. For a system whose core promise is censorship resistance, examine the threat model carefully before assuming Solana clears the bar.

The ecosystem cost is the other half of the decision. The deep, composable DeFi and tooling that lives on EVM chains does not all exist on Solana, and bridging assets across is a non-trivial, security-sensitive operation in its own right, not a free import. If your product needs to plug into existing on-chain protocols, that pull-toward-EVM is real and should be weighed against Solana’s raw performance. If your product is mostly self-contained and throughput-bound (payments, consumer apps, gaming), the performance wins and the smaller ecosystem rarely bites. Wavect ships in both Solana and EVM across the web3 stack. We have no chain bias; we have a use-case bias.

LoRaWAN is the networking layer that makes large-scale IoT economical. Devices run on coin-cell batteries for years, transmit small payloads (a few hundred bytes), and reach gateways kilometers away. The trade-offs: low bandwidth, infrequent updates, and a non-trivial deployment phase to get gateway coverage right.

The applications we have shipped include smart-city sensor networks (parking, environment, waste), agricultural monitoring, and industrial telemetry. The pattern is the same in all of them: cheap, dumb sensors at the edge; gateways aggregating to a network server; the network server forwarding to your application backend.

Worked example of where the budget actually goes, and the mistake founders make: they price the sensors and forget the coverage. A farm or a city district needs gateways positioned so that every sensor reaches at least one, and getting that wrong means dead zones, retransmissions, and batteries that drain in months instead of years. On a real deployment the site survey and gateway placement is often the harder half of the project, well after the per-unit sensor cost has been signed off. Walls, terrain, and metal silos all eat range, and you only find out by measuring on site.

The other decision founders rush is who owns the network. With LoRaWAN you typically run your own gateways, which means no per-device cellular bill but a real responsibility: you operate the gateways, the network server, and the coverage. The cellular alternatives (NB-IoT, LTE-M) flip that, the carrier owns coverage everywhere they reach, and you pay a per-device data plan in exchange. For a dense, fixed deployment you control (a campus, a farm, a city district), owning the network usually wins on cost over the device lifetime. For a low device count spread unpredictably across regions, paying the carrier is cheaper than building coverage you will barely use.

The honest trade-off: LoRaWAN trades bandwidth and latency for range and battery life, and that trade is non-negotiable, not tunable. It is the right tool when you need many sensors over a wide area with multi-year battery life and you only send a few bytes now and then. It is the wrong tool when you need high bandwidth, low latency, or per-device connectivity that follows the device around; for those, 5G NB-IoT or LTE-M is usually the better fit. Decide which axis your product actually lives on before committing to the radio.

An LLM is a model trained on enormous amounts of text to do one thing: predict the next token (roughly, the next word fragment) given everything that came before. Stack enough of that prediction together and you get fluent answers, summaries, translations, and code. That is the whole trick. It is not reasoning in the human sense, it is very good pattern completion.

This matters because it explains both the magic and the limits. An LLM has no memory of your business, no knowledge past its training cutoff, and no built-in guarantee that the fluent answer it produces is true. It will state a wrong fact with exactly the same confidence as a right one. That failure mode has a name, hallucination, and it is not a bug to be patched out, it is what next-token prediction does when it has no grounding. Treat the model as a tool, not an oracle.

Worked example of the right architecture: a company wants an assistant that answers questions about its own contracts. The naive build asks the raw model and gets confident, wrong citations. The working build wraps the model: RAG retrieves the relevant contract clauses at query time so answers come from the company’s documents rather than the model’s training data, output is validated against a schema, and anything that triggers a legal action routes through a human. The model did not get smarter; the engineering around it got serious.

The most common founder mistake is reaching for a bigger model to fix a grounding problem, or reaching for fine-tuning when the real need is retrieval. Fine-tuning changes style and format; it does not reliably inject facts, and it goes stale the moment your data changes. The honest trade-off: an LLM is the wrong tool when you need deterministic, auditable output (tax calculations, regulatory logic, anything where “usually correct” is a liability), and the right tool for drafting, classification, extraction, and search over your own data. Used in an agentic loop it can act, not just answer, which raises the stakes further. We build exactly this kind of grounded, validated system under Artificial Intelligence. Used as a source of truth, an LLM is a confident liability.

Prompt engineering is the practice of structuring what you send to an LLM: the task description, the examples, the constraints, the output format, and the context. The model has no idea what you want until you tell it, and how you tell it changes the result dramatically. A vague prompt gets a vague answer. A precise prompt with examples and a defined output schema gets something you can actually ship.

The hype frames this as a mystical skill. The reality is more mundane and more useful: it is iterative engineering. You write a prompt, you test it against real cases, you see where it fails, you tighten the instructions or add examples, you measure again. The system prompt (the standing instructions that sit above every user message) is where most of the durable behavior lives, so that is where the real work goes.

Here is the honest part: prompt engineering is real, but it is not a career moat. The techniques are learnable in a week, and the models keep getting better at understanding sloppy prompts. What does not commoditize is knowing which problem to point the model at, wiring it into a real system, and evaluating whether the output is good enough to trust. That is engineering, and it is what we do under Artificial Intelligence.

Worked example of the cheap-part / expensive-part split: a team gets a demo prompt working beautifully on five hand-picked inputs, declares the feature done, and ships. In production the same prompt fails on the messy real inputs nobody tested, because there was no RAG layer feeding it the right context and no evaluation harness measuring how often it was wrong. The prompt was never the hard part. Knowing the model’s context-window budget, wiring retrieval in, and measuring output quality on real cases is the work that actually ships a reliable feature. Watch for anyone selling “prompt engineering” as a standalone product: the prompt is the cheap part, and the expensive part is everything around it.

Fine-tuning takes a pretrained LLM and trains it further on a curated set of your own examples, adjusting the model’s weights so it leans toward the behavior you demonstrated. You use it to bake in a consistent tone, a specific output format, a domain vocabulary, or a task the base model handles awkwardly. It changes how the model responds, not what facts it has access to.

The decision that actually matters is fine-tuning versus RAG, and people get it backwards constantly. RAG injects fresh, changing facts at runtime by retrieving from your data, so the answer is only as current as your last document update. Fine-tuning teaches durable behavior but freezes the knowledge at training time, so it is the wrong tool when your facts change, and it will not reliably stop the model from inventing things either, since hallucination is reduced by grounding, not by tuning. The rule of thumb: tune for form, retrieve for facts. Many real systems use both, a fine-tuned model that answers in your house style, grounded by retrieval for the live data.

The cost reality is less scary than it used to be but still real. You need a clean, labeled dataset (usually hundreds to thousands of examples), the training run itself, and the ongoing cost of re-tuning every time the base model improves or your requirements shift. That last cost is the one teams forget. A fine-tune is not a one-time project, it is a maintenance commitment.

Worked example of fine-tuning winning outright: a company needs every model response to come back as strict JSON matching an internal schema, with a specific terse house style, across millions of calls. Prompting can get there most of the time, but the occasional malformed response breaks the downstream system, and stuffing the full style guide and schema into every prompt burns tokens on every call. A fine-tune bakes the format and tone into the model’s weights, so the instructions no longer have to be repeated in the context, which makes responses both more reliable and cheaper per call at that volume. That is the sweet spot: durable behaviour, high call volume, and a format that prompting cannot quite nail consistently.

When does fine-tuning win outright? When prompting plus retrieval cannot reliably produce the format or behavior you need, and you have enough high-quality examples to teach it. When in doubt, exhaust prompting and RAG first, because they are cheaper to change. We make this build-versus-tune call under Artificial Intelligence.

A vector database stores embeddings: numeric representations of text (or images, or audio) where similar meaning maps to nearby points in space. Instead of matching exact keywords, you embed the user’s query the same way and ask the database for the closest vectors. That is similarity search, and it is what lets a system find “how do I cancel my plan” when the document actually says “subscription termination procedure.”

In a RAG pipeline this is the retrieval layer. The quality of your answers depends heavily on it: good embeddings and good search return the right chunks to feed the LLM, bad ones feed garbage and the model confidently summarizes garbage. This is why retrieval, not the model, is usually where RAG projects succeed or fail.

Here is the part vendors skip: you often do not need a dedicated vector database. If your corpus is small (thousands, not millions of chunks), a vector extension on the Postgres you already run (pgvector) is simpler, cheaper, and one less system to operate. If your search is mostly keyword-driven, plain full-text search may beat vector search outright. Reach for a specialized vector DB when scale, latency, or hybrid search at high volume actually justify it, not because it is on the architecture diagram.

Worked example of over-engineering this: a team building an internal doc assistant over a few thousand pages reaches for a managed vector database, a separate embedding pipeline, and a reranking service before they have a single user. They now operate four systems to answer questions that pgvector on their existing Postgres would have handled, and every one is a new thing to monitor, secure, and pay for. The boring version ships in a week and scales fine until the corpus is genuinely large. Reach for the specialised database when the numbers force it (millions of vectors, strict latency budgets, high-volume hybrid search), not because the architecture diagram looks more serious with it.

We pick the boring-enough option deliberately under Artificial Intelligence, because every extra system is an extra thing to keep alive at 3am.

A hallucination is when a model generates something that sounds right and is wrong: an invented citation, a made-up API, a plausible but false fact. It is not a glitch you can patch out. An LLM predicts likely text, and a fluent, confident-sounding answer is statistically likely whether or not it happens to be true. The model has no internal sense of “I do not know,” so it fills the gap with something that fits the pattern.

Because it is structural, the honest framing is risk reduction, not elimination. The biggest lever is grounding: give the model the actual facts at runtime via retrieval (RAG) so it answers from real source text instead of its training-time guess. Note that fine-tuning is the wrong lever here, since it shapes behaviour rather than supplying facts. Constrain output formats so there is less room to improvise. Ask the model to cite sources you can check. And critically, evaluate, build a test set of real questions, measure how often the system is wrong, and treat that number as a quality metric you track like any other.

This is where AI meets QA, and most teams skip it. Shipping an LLM feature without an evaluation harness is shipping untested code and calling it done. You need to know your failure rate before your users find it for you. We treat that as non-negotiable under Software Quality Assurance.

Worked example of why the evaluation harness is non-negotiable: a team ships a legal-document assistant after testing it on a dozen questions by hand, all of which looked great. In production it confidently cites a clause that does not exist in the uploaded contract, a user acts on it, and now there is a real liability. The harness that would have caught this is unglamorous: a few hundred real questions with known-correct answers, run on every change, producing a single number, the percentage the system got wrong. Without it you do not know your failure rate, which means your users discover it for you, one bad answer at a time. With it, you can decide whether the rate is acceptable for the stakes before you ship.

The trust angle is the whole game in regulated or high-stakes domains. A hallucination in a chatbot that recommends a movie is a shrug. The same hallucination in financial, legal, or medical output is a liability. Match the guardrails to the cost of being wrong, and never let a fluent answer substitute for a verified one.

The context window is the LLM’s working memory for a single request, measured in tokens (a token is roughly three-quarters of a word). Everything has to fit inside it: your system prompt, the conversation history, any documents you paste in, and the answer the model generates. Exceed the window and the model literally cannot see the overflow.

“Just put everything in the prompt” fails for three reasons even when the window is large. First, cost: most providers charge per token, so stuffing a huge document into every call multiplies the bill. Second, latency: more tokens means a slower response. Third, and least obvious, quality, models attend less reliably to information buried in the middle of a very long context, so more is not always better. A focused prompt often beats a bloated one.

This is exactly why RAG exists. Instead of dumping your whole corpus into the window, you retrieve only the handful of relevant chunks for each question and send just those. You get the benefit of a large knowledge base without paying to process all of it on every request. The context window is the budget; retrieval and good prompt-engineering are how you spend it wisely.

Worked example of the “lost in the middle” effect that surprises teams: a company pastes a 40-page policy document into the prompt and asks a question whose answer sits on page 20. The model, with the whole document technically inside its window, still gets it wrong, because attention degrades for material buried in the middle of a long context. The same model, handed only the two relevant paragraphs that retrieval pulled out, answers correctly. Bigger windows did not fix the problem; better-targeted context did. This is the counter-intuitive part founders miss when a new model ships with a headline-grabbing window size: more capacity is not more reliability.

The practical takeaway: treat the context window as a scarce resource with a price tag, not free space. Bigger windows lower the pressure but do not remove it, and cost and latency still scale with what you put in. We design around that budget deliberately under Artificial Intelligence.

A blockchain is a database with two unusual properties. First, it is append-only: you can add records but you cannot rewrite the ones already there without every participant noticing. Second, no single party controls it. A network of nodes runs the same software and agrees on the next block through a consensus mechanism (proof-of-work, proof-of-stake, or a permissioned variant). The result is a ledger multiple parties can trust without trusting each other.

There are two broad kinds. A public blockchain (Ethereum, Bitcoin, Solana) is open: anyone can read it, run a node, or transact, and it is where smart-contract systems and the broader web3 stack live. A private or permissioned blockchain restricts who participates, which usually means you have rebuilt a slower, more complex version of a normal database with extra steps. If one company controls all the nodes, you do not have a blockchain advantage, you have a distributed system you now have to operate.

Worked example of the question that settles it: a logistics company wants a blockchain “so partners can trust the shipment data”. Walk the three tests. Do the records need to survive the company going bankrupt? Not really, the company is the one running the network. Do mutually distrusting parties need to share state without an operator? Closer, but in practice one party is clearly the hub and everyone connects to it. Do they need permissionless composability with other on-chain systems? No. So what they actually want is a well-permissioned shared database with an audit log and signed entries, which is cheaper, faster, and something their existing team can operate. The blockchain pitch was solving a trust problem that a signature and a read replica already solve.

The honest stance: most projects pitched as needing a blockchain do not. A blockchain earns its complexity only when you need assets that survive the operator’s bankruptcy, shared state between parties who do not trust each other, or permissionless composability. Everything else is a database. When a public chain is the right call, fees and throughput usually push the build onto a Layer 2 rather than the base layer. We have shipped real blockchain systems and we have talked clients out of more than we built. Our blockchain work starts with whether you need one at all.

A Layer 2 is a blockchain that borrows security from a Layer 1 (usually Ethereum) instead of running its own consensus from scratch. The L2 executes transactions off the base chain, bundles them, and posts the result back to L1. Most are EVM-compatible, so the same Solidity contracts and tooling carry over. Users get the security guarantees of Ethereum at a fraction of the cost and with much higher throughput. L2s exist because base-layer block space is scarce and expensive: when Ethereum is busy, a simple transfer can cost more than the thing being transferred.

The dominant design is the rollup, which comes in two flavours. Optimistic rollups (Arbitrum, Optimism, Base) assume transactions are valid and allow a challenge window during which anyone can dispute a fraudulent batch. ZK rollups use a zero-knowledge proof to mathematically prove each batch is valid before it lands on L1, which removes the challenge delay at the cost of heavier proving infrastructure. Optimistic is simpler and cheaper to build on today; ZK is where the technology is heading.

The detail that surprises users and burns founders who did not plan for it: withdrawals back to L1. On an optimistic rollup the challenge window means moving funds from the L2 to Ethereum mainnet can take around a week unless you pay a third-party “fast bridge” to front the liquidity. A consumer who deposited in seconds and expects to withdraw in seconds is not going to read your docs about fraud-proof windows; they are going to think your app is broken or stealing their money. If you build on an optimistic L2, the withdrawal experience is a product problem you have to design around from day one, not an implementation detail.

Wavect has shipped to production on an L2 (Boba Network), including its hybrid compute model that lets a smart contract call off-chain code mid-execution. That pattern is powerful for bringing real-world data or heavy computation into a contract, and it is genuinely hard to operate safely. If a vendor pitches an L2 deployment as a free scaling win, ask how withdrawals to L1 work, what the finality delay is, and who runs the sequencer. Our blockchain work covers L2 selection and deployment.

DeFi replaces the intermediary in a financial transaction with code. Instead of a broker matching trades, a decentralised exchange (DEX) uses an automated market maker: a smart contract that holds two assets in a pool and prices swaps by a formula. Instead of a bank deciding who gets a loan, a lending protocol lets anyone borrow against collateral they lock in a contract, often a stablecoin, with interest rates set algorithmically by supply and demand. Nobody approves you; the contract just executes.

The genuine innovation is composability. Because every protocol is a public contract on the same chain, they snap together like Lego. A position in one protocol can be collateral in another, which can be wrapped and traded in a third, all in a single transaction. This is something the traditional financial stack, with its walled APIs and settlement delays, cannot do. It is also why DeFi failures cascade: when one building block breaks, everything stacked on it breaks too.

The risks are real and specific. Smart-contract risk: a bug drains the pool, and there is no chargeback. Oracle risk: protocols depend on price feeds, and a manipulated oracle lets an attacker borrow against fake collateral.

The risk founders underestimate most is regulatory, not technical. In the EU, a business that builds on DeFi rails or offers DeFi-adjacent services can fall under MiCA, anti-money-laundering obligations, and licensing requirements that “decentralised” does not exempt you from. Regulators increasingly look at who actually controls and profits from a protocol, not at the marketing. If your model assumes the permissionless nature of DeFi means no compliance burden, price in a legal review before you ship, because getting the classification wrong is far more expensive than the contract work. We have shipped payment infrastructure that touches DeFi rails (Scramble), and our position is that DeFi is powerful for the narrow set of use cases that need permissionless, composable finance, and a liability for everyone using it as a yield casino. Our blockchain work starts with which one you are.

A DAO is a way to run a collective where the rules of membership, voting, and spending live in smart contracts. The treasury is an on-chain wallet that only releases funds when a proposal passes a vote. Voting power usually tracks token holdings or membership. The pitch is that coordination becomes transparent and tamper-proof: anyone can audit the treasury, every vote is recorded, and no single signatory can quietly drain the funds. It is one of the few web3 primitives whose value does not depend on a token price.

DAOs work well for a specific job: managing a shared on-chain treasury where the members do not fully trust each other and need verifiable rules for who can spend what. Investment clubs, protocol parameter governance, and grant funding are real fits. We built the on-chain governance and treasury logic for FTW DAO, where the structure earns its complexity because real money is pooled across parties.

The legal status is the part most DAO pitches gloss over, and in Austria and the wider EU it matters. A DAO is not a recognised legal form. Unless the members wrap it in an actual entity (a GmbH, an association, a foundation), a court may treat the participants as a partnership with joint and several liability, meaning a member could be personally on the hook for the collective’s obligations. “The code is the organisation” is a fine engineering principle and a dangerous legal one. Any DAO that touches real money or real counterparties needs a real legal wrapper underneath the smart contracts, decided before launch, not after the first dispute.

Where DAOs become theatre: governance over decisions that are not actually on-chain, token-weighted voting that concentrates power in a handful of whales, and “community governance” that is a marketing label over a team who still controls the admin keys. If the hard decisions still happen in a private chat and the vote is a rubber stamp, you have a normal company wearing a DAO costume. We will tell you which one you are building. See our blockchain work.

An NFT is a smart-contract token standard (ERC-721 on Ethereum is the common one) for assets that are not interchangeable. A dollar is fungible: any dollar is as good as another. A deed to a specific house is not. An NFT is the on-chain equivalent of that deed: a unique entry tied to one owner address, transferable, and verifiable by anyone. What the token actually represents is a design decision, and most of the value question hinges on getting that decision right.

The honest distinction is between utility and speculation. Real utility: tokenised ownership of a real-world asset (RWA), an access right that gates a service or event, a membership credential, or an in-game item the player genuinely controls. In these cases the NFT is doing a job a database row cannot, because the owner can transfer or sell it permissionlessly and it survives the issuer. We built NFT-backed mechanics for LivLive, where the token gates real-world experiences rather than serving as a collectible.

A detail that quietly breaks naive NFT projects: the token on-chain is usually just a pointer, and what it points to often lives on a normal web server. If that server goes down or the company stops paying for it, the “permanent” NFT now points at nothing, a broken-image link backed by a blockchain. Projects that take the ownership claim seriously store the referenced asset on content-addressed storage like IPFS or on-chain directly, so the thing the token represents survives as long as the token does. If a vendor cannot tell you where the actual asset lives and who keeps it alive, the permanence is marketing.

The speculation case is most of the market: a token pointing to a JPEG whose only value is the next buyer paying more. There is nothing technically wrong with it, but it is a collectibles market with blockchain settlement, not a productivity tool. If a vendor pitches NFTs for your business, the question is always the same: what does the token let the holder do that a database cannot, and does that ownership need to survive your company? Our blockchain work starts there.

A crypto wallet does not hold coins; the coins live on the blockchain. The wallet holds the private key that controls them, and uses it to sign transactions that move or spend assets. This is the whole game: whoever holds the key holds the assets. Lose the key and the funds are gone with no recovery line; leak it and an attacker drains the account instantly. Most wallets back the key up as a twelve-word seed phrase, which is the human-readable form of that single point of failure.

The first fork is custodial versus self-custody. A custodial wallet (an exchange account) holds the key for you, like a bank holds your money: convenient, recoverable by support, and only as safe as the company and as available as its solvency. A self-custody wallet puts the key in the user’s hands: nobody can freeze or seize the assets, and nobody can help when the user loses the seed phrase. This trade-off, between control and a safety net, is the defining UX problem of the whole space.

A regulatory line worth understanding, because it changes your obligations entirely: a genuinely self-custody wallet, where only the user can move funds and you never touch their keys, generally keeps you out of the money-transmitter and custody licensing regimes that govern exchanges. The moment your product can move user funds, hold keys, or step in to recover them, you may have crossed into custodial territory with all the licensing, KYC, and AML weight that carries. Recovery features are exactly where this gets subtle: a “social recovery” scheme where your company is one of the guardians looks very different to a regulator than one where only the user’s chosen contacts hold shares. Design the recovery model with the legal classification in mind, not just the UX.

Account abstraction is the most credible fix. By making the wallet itself a smart contract, you can add social recovery (trusted guardians restore access), gasless transactions, spending limits, and email-and-passkey signup instead of a seed phrase. We have shipped production self-custody wallets, including Scramble and MetaMask Snaps, and our view is that seed-phrase-only wallets are a dead end for mainstream web3 users. The recovery story has to be solved before a non-technical person should hold meaningful value. See our blockchain work.

A stablecoin is a token that tries to stay pegged to a stable asset, almost always the US dollar. The point is to keep the settlement speed and global reach of a blockchain without the volatility that makes Bitcoin or ETH useless as a unit of account. You can hold, send, and receive a stablecoin like email for money: final in seconds, across borders, without a bank in the loop. That is the genuine use case, especially for payments and remittance into and out of regions with weak banking infrastructure.

How the peg holds defines the risk. Fiat-backed stablecoins (USDC, USDT) hold real dollars and treasuries in a bank account and mint one token per dollar. The peg is only as good as the reserves and the issuer’s honesty, which is why reserve attestations matter. Crypto-collateralised stablecoins (DAI) overcollateralise with on-chain assets, trading custody risk for liquidation risk in a market crash, and they are the backbone of most DeFi lending. Algorithmic stablecoins try to hold the peg with supply mechanics and no real backing, and the graveyard (Terra/UST, billions evaporated) is the reason serious operators avoid them.

The EU regulatory picture is now concrete, not theoretical. Under MiCA, stablecoins (e-money tokens and asset-referenced tokens) are explicitly in scope, with reserve, disclosure, and issuer-authorisation requirements, and the rules constrain how non-euro stablecoins can be used for everyday payments at scale within the bloc. For any business building payment flows on stablecoin rails in Austria or the wider EU, the question is no longer “is this allowed” but “which coin, issued by whom, under which authorisation”. That is a design decision to make before you write the integration, because retrofitting compliance onto a launched payment product is the expensive path.

We built payment infrastructure on stablecoin rails (Scramble) and worked on stablecoin-adjacent systems (Zybra), so the position is grounded: stablecoins are the most genuinely useful web3 primitive for moving value, and the peg is never free. Always know what backs the coin, who can freeze it, and what happens in a run. Our blockchain work treats the peg model as a first-class design decision.

Microservices means breaking an application into many small services, each owning one piece of the business and each deployable on its own. Instead of one program where everything runs in the same process, you get a fleet of services talking to each other over the network. The promise is real: teams can ship independently, you can scale only the parts that need it, and one service can fail without taking the whole system down.

The cost is also real, and it is usually underestimated. The moment your function calls become API calls over the network, you have a distributed system, and distributed systems are hard. You inherit network failures, latency, data spread across many databases with no easy transactions, versioning between services, and the operational burden of running, monitoring, and debugging many moving parts instead of one, which raises the bar on your CI/CD maturity. A bug that used to be a stack trace is now a trace across five services and three queues.

The honest stance: most startups should start with a monolith. A well-structured single application is faster to build, far easier to debug, and perfectly capable of carrying you to real revenue. You split into microservices when you have a concrete reason, a team large enough that one codebase is a bottleneck, or a workload that genuinely needs independent scaling, not because microservices are the fashionable answer. Premature microservices are how small teams turn one hard problem into ten.

Polity ran on seven microservices, and that was the right call for its scale and team structure. That is the point: the architecture should follow the problem and the org chart, not a conference talk. Pick the boundaries where they actually reduce coupling, and accept that every boundary you draw is a network call you now have to defend.

An API is the defined way one piece of software talks to another. It says: here are the things you can ask me to do, here is exactly how you ask, and here is what you get back. The whole point is that the caller does not need to know how the work is done internally, only what to send and what to expect. Your phone’s weather app does not know how the weather service works. It just knows the API, sends a request, and gets a forecast.

The key idea is the contract. Both sides agree on the shape of the requests and responses, and as long as that contract holds, either side can change its internals freely. That same contract discipline is what lets a microservices architecture hold together, and it is the idea MCP standardises so AI models can call tools without bespoke glue. The two common styles you will hear about are REST, which models everything as resources you read and write over standard web requests and is the default for most web and mobile backends, and GraphQL, which lets the caller ask for exactly the fields it wants in one request. Both are just disciplined ways of defining the same contract.

API design is one of the most durable decisions you make. Internal code you can refactor over a weekend. A public API has other people’s software depending on the exact shape of it, so changing it breaks their integrations, which means you often cannot change it at all without a painful versioning exercise. A clean, well-named, consistent API ages well. A sloppy one becomes a permanent tax you pay on every future change. We treat API design as a first-class part of software development, not an afterthought bolted on at the end.

The honest take: most “the integration is a nightmare” complaints trace back to an API that was designed in a hurry to ship one feature, then forced to carry ten. Spend the time on the contract early. It is the part you will least be able to change later.

SaaS is a delivery and business model, not a technology. Instead of selling you a copy of the software to install and run yourself, the vendor hosts it, operates it, and gives you access over the web for a recurring fee. You log in, you use it, you never touch the servers. Salesforce, Slack, and Notion are SaaS. The customer rents capability rather than buying and maintaining software.

The defining technical trait is multi-tenancy: one running system serves many customers at once, with their data isolated from each other. That single choice shapes everything. You design for isolation and security between tenants, for deploying updates to everyone at once without breaking anyone, and for scaling as customers are added rather than shipping a new version once a year. Whether that scaling lives in a monolith or in microservices is a separate decision that should follow the load, not the fashion. It also changes operations, because the vendor now carries uptime, backups, and security as an ongoing responsibility, not the customer.

The business model is the other half. Revenue is a subscription, usually monthly or annual, which means the relationship does not end at the sale, it starts there. The metrics that matter become recurring revenue, churn, and the cost to serve each customer. Pricing usually ties to value or usage: per seat, per tier, or per volume. Get the pricing model wrong and a technically excellent product still loses money on every customer, so pricing is an architecture decision as much as a sales one.

We build SaaS products end to end, from the multi-tenant architecture to the web app customers log into, usually starting from an MVP and hardening it once the product finds PMF. Polity is a SaaS product. The honest part founders underprice: the recurring model means you are signing up for permanent responsibility for uptime, security, and support, which is a real operating cost, not a one-time build.

Agile is older than most people realise (the manifesto is from 2001) and worse-implemented than most teams will admit. The original idea was simple: planning further out than you can predict is wasted work, so plan short, ship, learn, replan. Everything else (Scrum, Kanban, SAFe, sprints, retros, story points) is implementation detail layered on top.

The most useful question for a team that says it is “doing agile” is: when was the last time the plan changed because of what shipped last week? If the answer is never, the team is doing waterfall in two-week chunks.

Worked example of the difference: two teams both run two-week sprints. Team A demos, sees that the feature nobody on the roadmap predicted is the one users actually click, and reorders next sprint around it. Team B demos, notes the feedback in a doc, and proceeds with the plan they wrote in January because the plan is the plan. Team A is agile. Team B has agile ceremonies and a waterfall brain. The ceremonies are identical; only the willingness to act on evidence differs, and that is the whole ballgame.

The honest trade-off and the founder mistake: agile is not a license to skip planning, and it is not free. It trades long-horizon predictability for fast learning, which is exactly wrong when scope, regulation, or an interface contract genuinely cannot change (certified medical devices, avionics, some hardware). Even there the original principles apply inside the team; the public-facing process just looks more like waterfall. Wavect is agile in the original sense: we work in short cycles, demo often, lean on CI/CD so shipping is cheap, and we are willing to throw out work that turned out to be wrong. We are skeptical of the certification-industry version of agile, where the meeting cadence becomes the goal and a TDD suite gets written for show rather than for confidence.

Test-Driven Development is a discipline, not a methodology. The loop is: red (write a failing test), green (write the simplest code that passes), refactor (clean up without breaking the test). Done literally, it produces code with high test coverage and a forcing function against over-engineering. The discipline only pays off when those tests run on every change, which is why TDD and CI/CD are siblings, not separate concerns.

The reason most teams say they do TDD but actually do not: writing the test first feels slower in the moment. The compounding payoff (refactor safety, regression coverage, design pressure toward smaller units) only shows up months later. By then the team has stopped writing the tests first and convinced itself it never made a difference.

Worked example of where TDD earns its cost versus where it is theatre: a payments reconciliation module has gnarly edge cases (partial refunds, currency rounding, retries). Writing the failing test first forces you to state the expected behaviour before the code exists, and the suite catches the regression six months later when someone “simplifies” the rounding. That is TDD paying for itself. Now contrast a throwaway data-import script you will delete in two weeks: writing tests first there is pure overhead. The honest rule is to TDD the logic-heavy, expensive-to-get-wrong code and not the rest.

The most common mistake is treating coverage as a target. Chase 90% and the team writes tests for getters and setters to hit the number while skipping the integration tests where the real bugs live. Coverage is a useful diagnostic and a terrible goal; it is a metric to game. Wavect uses TDD where it pays: integration tests for anything money-shaped, contract tests for anything customer-facing, BDD-style acceptance tests where product needs to read them, unit tests for non-trivial logic. We test the hard parts well, not all parts equally, and we treat it as one practice inside a healthy agile loop rather than a box to tick.

Behavior-Driven Development is TDD with the test language rewritten to be readable by non-engineers. Tools like Cucumber use a Given/When/Then format that a product manager can sign off on. The intent is to keep tests aligned with the business behavior they validate, instead of with the implementation that happens to exist today.

Worked example of where this actually pays: an insurance product has a rule that a claim under 30 days old with a valid policy gets auto-approved. Written as a Gherkin scenario (“Given a policy active for 30 days, When a claim is filed within the cover window, Then it is auto-approved”), the product owner and the compliance reviewer can read it, confirm it matches the real rule, and catch the off-by-one before it ships. That shared-language check is the entire value of BDD, and it lives at the acceptance and integration layer where the gap between what product meant and what engineering built is where bugs are born.

There is also a maintenance cost teams discover late. Gherkin scenarios sit on top of a layer of “step definitions”, glue code that maps each plain-English line to actual test actions. That glue is real software that has to be kept in sync as the product changes, and a large BDD suite with sloppy step definitions becomes its own maintenance burden, slow to run and brittle to edit. The benefit (a stakeholder can read and sign off the behaviour) only pays for that overhead when a stakeholder actually reads them. If the Gherkin is written by engineers, read by engineers, and never seen by anyone else, you are paying for a translation layer with no audience.

The honest trade-off and the common mistake: BDD is not a replacement for TDD, it is a layer on top, and applying it everywhere is the error. Writing “Given two numbers, When I add them, Then I get the sum” for a trivial function is ceremony that no business stakeholder will ever read. Save Gherkin for the tests a non-engineer genuinely needs to sign off on, and use plain unit tests below that line. Like all of these practices, BDD is one stage in a sane SDLC and a tool for a real communication problem, not a process to adopt for its own sake.

The word “viable” does the work in MVP, and almost everyone gets it wrong. Viable does not mean “a stripped-down version of the eventual product”. Viable means “sufficient to test the hypothesis that this product is worth building”. A landing page with a waitlist can be an MVP. A working product with three features can be a worse MVP than the landing page.

Worked example: a founder is convinced their hypothesis is “users will pay for automated invoice reconciliation”. The instinct is to spend three months building the reconciliation engine. The cheaper MVP that tests the actual hypothesis is a manual one: a landing page, a price, and a human doing the reconciliation by hand behind the scenes (a Wizard-of-Oz MVP). If nobody pays for the manual version, the engine would have been three wasted months. The build only starts once the willingness-to-pay is proven, which is exactly the kind of de-risking a discovery-phase is for.

There is an Austrian funding wrinkle worth knowing. aws Preseed and similar grants are often framed around reaching a “prototype” or “MVP” milestone, and founders sometimes let the grant’s definition dictate the build, padding the MVP with features that tick a funding box rather than test a hypothesis. Use the money to learn faster, not to build a heavier MVP than the learning requires. The grant rewards a milestone; the market rewards a validated assumption, and those are not always the same artifact.

The most common failure is building the MVP you imagined six months ago instead of the MVP that tests this week’s most uncertain assumption. Every week the riskiest assumption shifts, and most MVPs are obsolete before they ship. The honest trade-off: an MVP deliberately under-builds, so it will look unimpressive next to the polished thing in your head, and that discomfort is the price of learning fast. If the build phase runs past 8 to 12 weeks you are not building an MVP, you are building V1 under a kinder name. Wavect runs short agile cycles toward an MVP and names the hypothesis before scoping the build. Related: Fractional CTO Austria covers MVP leadership end to end.

Product-Market Fit is famously hard to define and famously easy to recognise. Marc Andreessen’s heuristic still holds: you know you have it when the product is being pulled by users, the press, and the cap table all at once, and your problem is no longer how to find customers but how to keep up with them.

Pre-PMF, almost everything you do is a bet. The right org chart, the right tech stack, the right hiring plan all depend on which segment of customers actually pulls. Post-PMF, the questions become operational: scale the team, harden the stack, control the burn.

Worked example of the most expensive pre-PMF mistake: a team raises a seed round, hires four engineers, and spends nine months building a Kubernetes-backed, multi-region, microservices platform “so we can scale”. They scale to forty users, run out of runway, and the architecture they built for millions never gets tested by hundreds. The opposite failure is rarer but real: a team finds the pull, gets featured, and the single overloaded server falls over during the one week the whole market was watching. The engineering call is entirely a function of which side of the PMF line you are on, which is why naming the line honestly matters more than any stack decision.

The honest trade-off founders dodge: admitting you are pre-PMF feels like admitting failure, so decks describe a slog of one-customer-at-a-time selling as “early traction”. If acquisition is still a grind and churn is high enough that word of mouth cannot carry growth, you are pre-PMF regardless of the deck, and the right move is to keep shipping the cheapest MVP that resolves the next uncertainty rather than build for a scale you have not earned. A discovery-phase helps you name the riskiest assumption; a fractional operator can prevent expensive technical mistakes during the search, but cannot substitute for the founder’s relentless customer obsession that actually produces the pull. Past PMF, you typically need a CTO, not a co-founder. See Fractional CTO Austria.

Software Development Lifecycle is the umbrella term for the stages software goes through from idea to retirement. Different methodologies (agile, waterfall, devops, continuous delivery) define different stage boundaries and different ways of moving between them. The stages themselves are roughly invariant: discovery, design, build, test, deploy, operate, retire.

Useful as a vocabulary, not as a process. Teams that try to enforce a strict SDLC end up with documentation overhead that does not survive the second sprint. Teams that ignore the SDLC entirely end up rediscovering each phase the painful way (“we shipped without a deploy plan”, “we did not think about how to retire this”).

Worked example of the stage everyone skips: a startup builds three internal services over two years, ships them, and moves on. Nobody owns “operate” and nobody planned “retire”. Eighteen months later two of the three services are still running, nobody remembers why, the one engineer who understood them has left, and disabling either might break something or might not. That is the unbilled cost of skipping the back half of the lifecycle. The fix is cheap if done up front (name an owner, write a deploy and a teardown plan) and expensive if discovered later.

The methodology you pick mostly decides how rigid the boundaries between stages are. A waterfall SDLC runs them strictly in sequence with sign-offs at each gate; an agile SDLC interleaves design, build, and test continuously and revisits earlier stages as it learns. The stages are the same set either way, which is the useful insight: arguing “agile versus waterfall” is really arguing about how permeable the boundaries should be, and the right answer depends on how much your requirements can still change.

The honest trade-off and common mistake: founders hear “SDLC” and either over-formalise it into a gated, sign-off-heavy process that kills speed, or dismiss it as enterprise theatre and skip the unglamorous stages. The right posture is to treat it as a checklist of things that must happen somewhere, not a sequence to march through. Wavect’s preferred shape: a paid discovery-phase up front, design and build interleaved in short cycles, automated TDD and CI/CD from day one, operate with clear ownership, retire with documented migration paths.

Continuous Integration means the team’s code is merged and built on every change, not in a big-bang integration at the end. Continuous Delivery means every successful build is one button-press away from production. Continuous Deployment removes the button: every green build ships, automatically. The three are a maturity ladder, not synonyms.

Most teams do CI well, CD intermittently, and Continuous Deployment almost never. The bottleneck is rarely the tooling. It is the trust in the test suite and the team’s willingness to fix a broken build inside an hour. Without those, automated deploys just ship bugs faster.

Worked example of the leverage hiding in pipeline speed: a team has a CI pipeline that takes 25 minutes. Engineers stop running it locally, batch their changes, and merge on hope to avoid the wait. Bugs accumulate between merges and the integration pain the team adopted CI to avoid quietly comes back. Cut that pipeline to under 10 minutes for the inner loop and engineers run it constantly, catch problems while the context is fresh, and the whole agile loop tightens. Pipeline speed is not a nice-to-have; it is a force multiplier on every engineer’s day.

The honest trade-off and the common mistake: founders ask for “full CI/CD” as if it is a single switch, when CI is mostly tooling and CD is mostly discipline. CI you can have in an afternoon. True Continuous Delivery requires a test suite the team trusts behind a TDD habit, a rollback path measured in minutes, and someone on call to respond when a deploy lights something on fire. Wavect ships every project with CI configured from day one as part of a sane SDLC; CD configuration depends on whether the project has the coverage and operational discipline to make it safe. We will tell you which one you have.

Continuous Delivery is the responsible cousin of Continuous Deployment. Every change goes through the same automated build, test, and release-preparation pipeline (the CI/CD backbone). The artifact that comes out is shippable. Whether it actually ships is a human call.

The reason most teams stop at CD instead of going to full Continuous Deployment: the cost of a bad deploy is high enough that one human in the loop is worth the latency. Move to Continuous Deployment when your monitoring, test coverage, and rollback story are good enough that the human is no longer adding signal.

Worked example of choosing per service, not per company: the same business runs a marketing site and a payments ledger. The marketing site is a great fit for full Continuous Deployment, where a bad deploy means a typo and a rollback is trivial, so every green build can ship unattended. The payments ledger stays on Continuous Delivery with a human pressing the button, because a bad deploy there moves money incorrectly and the human is genuinely adding signal, not just latency. Treating “should we automate deploys” as one company-wide decision is the mistake; it is a per-service risk judgement.

There is a regulatory dimension worth naming. In domains with change-control or audit requirements (finance, health, anything touching personal data under GDPR), the human approval step in Continuous Delivery is not just risk management, it is often the documented control an auditor expects to see: who approved this release, against what evidence, when. Teams in those settings should not chase full Continuous Deployment as a maturity badge; the manual gate is a feature their compliance story depends on. Automate everything up to the button, then keep the button where the audit trail needs it.

The honest trade-off: Continuous Delivery buys you most of the speed of full automation while keeping a human veto on the irreversible step, at the cost of that veto being a bottleneck if the human is slow or absent. The prerequisite for graduating past it is real, not aspirational: a TDD-backed suite the team will ship behind, a minutes-not-hours rollback, and an on-call rotation. Without those three, “Continuous Delivery” is a button nobody dares press, and the pipeline is decoration on top of an otherwise healthy SDLC.

Scrum is one implementation of agile principles, with three roles, three artifacts, and a handful of events. The Product Owner decides what gets built and in what order. The Scrum Master removes blockers and protects the process. The developers build it. The artifacts are the product backlog (everything that might get built, usually written as user stories), the sprint backlog (what this sprint commits to), and the increment (what actually ships). The events are sprint planning, the daily standup, the sprint review, and the retrospective.

Where Scrum genuinely helps: teams that struggle with focus and visibility. The fixed sprint forces a real commitment, the review forces a real demo, and the retro forces the team to look at its own process instead of ignoring it. For a team that has never shipped on a cadence, Scrum is a useful scaffold.

Where it becomes theatre: when the events survive but the substance dies. A standup that is a status report to the manager. A review with no working software to show. A retro that produces the same three action items every fortnight and acts on none of them. Many “Scrum” teams are running the ceremonies and getting none of the value. If you are doing the meetings but cannot demo a working increment, you do not have Scrum, you have a meeting habit.

Worked example of the overhead trap: a five-person team adopts Scrum by the book and ends up with sprint planning, a daily standup, a backlog refinement session, a sprint review, and a retro every two weeks. On a team that size, that ceremony load can eat the better part of a day a week per person, and the planning precision it buys is wasted because a five-person team already knows what everyone is doing. The framework was designed to coordinate teams that had lost that visibility; imposing all of it on a team that never lost it is pure tax. The fix is not to abandon the feedback loops (keep the demo and the retro) but to drop the coordination ceremonies that are solving a problem you do not have.

Wavect’s honest take: Scrum is a good starting framework and a bad religion. Keep the parts that create feedback and drop the parts that create overhead. Most mature teams drift toward something lighter, often closer to Kanban, once the discipline is internalised.

Kanban has two core ideas: make the work visible, and limit work in progress. You put every item on a board with columns for each stage (to do, in progress, review, done), and you cap how many items can sit in each active column at once. When a column is full, nobody starts new work until something moves out. That cap is the whole point: it forces the team to finish things before starting more.

The contrast with Scrum is the cadence. Scrum batches work into fixed sprints and re-plans at each boundary. Kanban has no sprints. Work is pulled continuously as capacity frees up, and you can change priorities at any moment without waiting for a sprint to end. There is no commitment ceremony, no sprint review, no artificial two-week box. Both are implementations of the same agile goal: tight feedback and the ability to change course on evidence.

Pick Kanban when work arrives unpredictably and interrupt-driven (support, operations, platform teams), or when a team is mature enough that the sprint scaffolding has become pure overhead. Pick Scrum when a team needs the rhythm and the forced review to build delivery discipline, or when stakeholders need a predictable demo cadence to plan around.

Worked example of what a WIP limit actually does to a team: an “in progress” column capped at three, on a team of five, means two people will sometimes have nothing of their own to start. The instinctive reaction is that this is waste, idle engineers. It is the opposite. Those two are now forced to help finish the three things already in flight, review a teammate’s work, or pair on the blocker, instead of opening a fourth task and spreading the team thinner. The discomfort of a full column is the mechanism working: it converts “everyone busy, nothing shipping” into “fewer things in flight, things actually finishing”. Teams that cannot tolerate that brief idleness quietly raise the limit until it stops constraining anything, and then wonder why throughput did not improve.

The honest version: WIP limits are where the value is, and they are also the part teams quietly ignore. A Kanban board with no WIP limit is just a to-do list with extra columns. If the team is starting five things and finishing none, the limit is the fix, not a bigger board.

Technical debt is a metaphor, and a good one. When you take a shortcut to ship faster (a quick hack instead of the clean design, a hard-coded value instead of the config system), you borrow time now and pay it back later as interest: every future change in that area is slower, riskier, and more annoying. Like financial debt, it is not automatically bad. It is a tool.

Taking debt deliberately is often the correct call. Before product-market fit, speed beats elegance, because most of what you build will be thrown away anyway. Building a pristine architecture for a product that might not exist in six months is its own kind of waste, which is the whole logic of shipping an MVP. The right move is frequently to take the shortcut, ship, learn, and pay the debt down once you know the thing is worth keeping.

The danger is not debt. The danger is invisible debt. Deliberate, documented debt (“we hard-coded this, here is the ticket to fix it before we scale”) is a managed liability, and a healthy CI/CD pipeline plus a sane SDLC are what surface it before it compounds. Undocumented debt that nobody decided to take, that just accreted through hurry and turnover, is the cruft that quietly strangles a codebase. Velocity drops, nobody can say why, and every estimate doubles. By the time it is visible in the metrics, the interest payments have been compounding for a year.

Wavect’s stance: debt is a deliberate trade-off, not a moral failing. We will happily take debt to hit a window, and we will write down exactly what we took and what it will cost to repay. The conversation we refuse to skip is the one where someone is paying interest and nobody has named the loan. See our full-stack development work for how we keep this trade-off explicit.

DevOps started as a reaction to a specific dysfunction: developers threw code over a wall to a separate operations team, ops got blamed when it broke, and the feedback loop between writing software and running it was broken. DevOps closes that loop. The team that builds the software also ships it and runs it, and the pain of operating something flows straight back to the people who can fix it.

In practice that culture is enabled by automation: CI/CD so changes flow to production safely and often, continuous delivery discipline so every build is shippable, infrastructure as code so environments are reproducible instead of hand-built snowflakes, and observability (logs, metrics, traces, alerts) so the team sees what production is actually doing. None of these tools are DevOps on their own. They are what makes the culture survivable.

The “DevOps engineer” job title is mostly a misnomer, and a revealing one. DevOps is not a role you hire to sit between dev and ops, that just rebuilds the wall with a new name. What most “DevOps engineer” postings actually want is a platform or infrastructure engineer who builds the automation other developers use. Useful person, wrong label. If your org has a DevOps team that owns deploys so developers do not have to, you have ops with a rebrand, not DevOps.

Worked example of “you build it, you run it” working as intended: an engineer ships a change on Thursday, gets paged at 2am Friday when it causes a slow memory leak, and spends the early hours fixing their own code. That is unpleasant once. It is also the most effective code-review system ever invented, because that engineer will never ship that class of bug again, and the next time they design something they will think about how it behaves at 2am. When a separate ops team absorbs that pain instead, the person who could prevent the next leak never feels the consequence of the last one, and the same mistakes recur indefinitely. The pager is not punishment; it is the feedback loop.

Wavect’s take: DevOps is a way of working, not a department. We build the automation that lets a small team own its software end to end, and we treat “you build it, you run it” as the default. See our full-stack development work for how that plays out in practice.

Waterfall runs a project as an ordered sequence of phases: gather all the requirements, then design the whole system, then build it, then test it, then deploy it. Each phase produces a signed-off document and finishes before the next one starts. The appeal is obvious: you know the plan, the cost, and the date up front, and everyone agrees to it before a line of code is written.

It still legitimately fits some work. When the scope is genuinely fixed and well understood, when a regulator requires up-front documentation and traceability, or when you are building hardware where you cannot cheaply iterate after the metal is cut, sequential phases are the honest model. Pretending such a project is “agile” just hides the plan instead of removing it.

The contracting angle is where Waterfall and Agile collide most concretely. A fixed-price Werkvertrag, under Austrian and German law, needs a defined deliverable to bind the vendor to, which pushes naturally toward a waterfall-shaped, fully-specified scope. Genuinely iterative work, where you expect the requirements to change as you learn, fits a Dienstvertrag or a retainer better. Founders get into trouble when they want the legal certainty of fixed-price and the flexibility of agile at the same time: those pull in opposite directions. The honest resolution is usually to do a fixed-price discovery to nail down enough scope to fix a price on, then run the build with whatever boundary permeability the remaining uncertainty actually warrants.

It fails badly for product discovery. The fatal assumption is that you can specify the right product up front, before any user has touched it. You almost never can. By the time the build phase ends, the requirements gathered months earlier are partly wrong, and Waterfall has no cheap way to find out until the testing phase, when changing anything is expensive. You get a product that matches the spec and misses the need.

The honest distinction from Agile: Waterfall front-loads all the decisions and bets that they are right. Agile (whether run as Scrum or a lighter flow) spreads decisions across the work and bets that early feedback will catch the wrong ones. Either way, both are just sequencing choices over the same underlying SDLC stages. For anything where you do not yet know exactly what to build, the bet favours Agile. For anything where the answer is genuinely known and fixed, Waterfall’s predictability is a feature, not a flaw.

A user story captures a piece of value from the perspective of the person who wants it, usually in the format “As a [role], I want [goal], so that [benefit]”. It is the unit most agile teams use to fill a sprint backlog. The format is not bureaucracy for its own sake. The “as a” forces you to name who actually wants this, and the “so that” forces you to state why, which is the part teams skip and then build the wrong thing. A story is a placeholder for a conversation, not a contract.

Good stories tend to satisfy the INVEST criteria: Independent (can be built on its own), Negotiable (the details are open until you discuss them), Valuable (delivers something a user or buyer cares about), Estimable (the team can size it), Small (fits inside an iteration), and Testable (you can tell when it is done). The last two are where most stories fall apart: too big to finish, or written so vaguely that nobody can say what “done” means.

Acceptance criteria are how a story becomes testable, and writing them in a BDD Given/When/Then form is the cleanest way to do it. They are the concrete conditions that must hold for the story to be accepted, written before the work starts. “As a user I want to reset my password” is an intention. The acceptance criteria (a reset link expires after an hour, an invalid token shows a clear error, a successful reset logs the user in) are what the team actually builds and tests against.

The common anti-pattern is the story that is a task in disguise. “As a developer I want to add an index to the orders table” has the user-story costume on, but there is no user and no benefit, just an engineering task wearing a hat. That is fine to track, but it is not a user story, and dressing technical tasks as stories quietly erases the user perspective the format exists to protect.