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.

In a Wavect engagement, a CTPO is usually fractional. 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.

The risk: one person becomes the single point of failure. The mitigation: a CTPO who knows when to stop being one and recruit their replacement. Anyone unwilling to fire themselves is the wrong CTPO.

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. They are the operator who decides which fires get fought and which get acknowledged-and-deferred.

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+ engineers reporting in and is mostly running engineering. A fractional CTO is brought in to cover the gap when neither of those two profiles is yet justified by revenue.

The most common mistake we see: hiring a scale-up CTO when the company needs a founding one. The CV is impressive, the runway evaporates in six months. Match the profile to the stage.

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.

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.

For pre-PMF companies a dedicated CPO is usually overkill. The role gets absorbed by the founder or the CTPO until the engineering team is large enough that someone needs to spend full time on what to build next.

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. 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.

We are not for everyone. If you need a body to grind tickets, hire a contractor. If you need someone to challenge your roadmap, sit on a hard architecture decision with you at 11pm on a Sunday, and tell you when your favorite feature is the wrong one, this is the shape of engagement you want.

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.

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.

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.

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.

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.

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. Conflating the two roles is the most common mistake we see in series-A startups.

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.

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.

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. A Time & Material contract under the same legal framework is a Dienstvertrag, which only obliges effort. Wavect’s fixed-price engagements are Werkvertrag contracts.

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. This is not legalism; it is the only way both sides can agree on what "done" means without arguing six months in.

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.

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 Statement of Work without the legal teeth.

Wavect uses T&M for exploratory engagements where the scope genuinely cannot be defined upfront. We do not use it as a default. 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. "Fixed price" as a verbal promise with a Time & Material contract underneath is not a fixed price; it is a marketing line.

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.

Wavect’s fixed-price guarantee means signed SoW (Werkvertrag), legally bound to deliver. It does not mean refund-if-we-miss-the-deadline.

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.

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.

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.

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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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), 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.

Wavect’s posture: start by asking if AI is the right tool here, then if an agent is the right shape of AI for it. Most workflows that get pitched as "agentic" are better served by a deterministic pipeline with one LLM call in the middle.

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.

For businesses the practical implication is leverage. Internal tools, databases, and APIs wrapped in an MCP server become usable by whichever LLM your team is on this quarter, with no rewrite when you switch. The trade-off is that MCP is still young: tooling, security models, and audit patterns are maturing. We build MCP servers regularly and have shipped them to production; we also still write a security review for each one because the standard is moving.

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.

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.

The unsexy truth about RAG: 80% of the work is making retrieval good (chunking strategy, embeddings choice, reranking, hybrid search) and 20% is the model itself. 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.

Wavect writes smart contracts in Solidity (EVM chains) and Rust (Solana, Near, ICP). For any contract holding non-trivial value we recommend a third-party audit before mainnet deployment. We have shipped audited contracts to production; the audit cost is usually 1 to 2 weeks of the build budget.

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.

Note that EVM-compatible is not the same as Ethereum-equivalent. Subtle differences in gas pricing, precompiles, and consensus behavior catch teams who deploy without re-testing per chain.

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.

Wavect ships in both Solana and EVM. 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.

LoRaWAN is the right tool when you need many sensors over a wide area with multi-year battery life. It is the wrong tool when you need high bandwidth, low latency, or per-device cellular plans (5G NB-IoT is usually a better fit for the latter two).

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.

Wavect is agile in the original sense: we work in short cycles, demo often, 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.

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 very high test coverage and a forcing function against over-engineering.

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.

Wavect uses TDD where it pays: integration tests for anything money-shaped, contract tests for anything customer-facing, unit tests for non-trivial logic. We do not write tests for getters and setters. Coverage as a target is a metric to game.

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.

In practice the value is highest at the integration and acceptance test layers, where the language barrier between engineering and product actually causes bugs. At the unit-test layer BDD adds more ceremony than it saves.

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.

The most common failure: building the MVP you imagined six months ago instead of the MVP that tests this week’s most uncertain assumption. Every week the assumption you should be testing changes. Most MVPs are obsolete before they ship.

Wavect’s discovery phase exists in part to fix this. Before scoping the MVP build, we name the hypothesis it needs to test. If the hypothesis is "users want feature X", the MVP is not a polished feature X; it is the cheapest possible way to find out.

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.

The reason this matters for engineering decisions: a pre-PMF team that over-builds for scale is wasting runway. A post-PMF team that under-builds will be eaten by its own success. Wavect engages differently across this line. Pre-PMF: ship the cheapest version that lets you learn. Post-PMF: harden, document, and start sleeping at night.

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

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").

Wavect’s preferred shape: discovery up front, design and build interleaved in short cycles, automated test and deploy 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.

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.

Wavect ships every project with CI configured from day one. CD configuration depends on whether the project has the test coverage and the 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 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.