Vedspace Ventures builds a venture in seven stages: discover the problem, validate the riskiest assumption, design the product and model together, build a first version that can be operated, launch to real users, scale what the evidence supports, and set the venture up to run independently. Every venture needs its own decisions, but the order of the questions stays the same, which is what makes progress comparable across very different opportunities. The studio brings problem discovery, product strategy, experience design, engineering and operating thinking into one team, so the people who test an assumption are the people who scope the build that follows it.
7 stages from first question to operating company
Each stage produces a decision and an output. A venture moves on when the evidence supports it, and pauses when it does not.
Discover — understand the problem before the product
Every venture begins with a problem someone already works around. We map who experiences it, what they do today, and what that workaround costs them in time, money or risk. Desk research, conversations with operators and a written problem statement come out of this stage. Discovery ends when the problem can be described in the user's own language and the single assumption most likely to sink the idea has been named.
Validate — test the riskiest assumption first
Validation is deliberately cheap. We take the assumption identified in discovery and design the smallest test that could disprove it: a clickable prototype, a landing page, a manual version of the service or a short pilot with real users. Demand, willingness to pay and regulatory constraints are examined here rather than after a build. A venture moves forward when the evidence supports it and pauses when it does not.
Design — shape product, model and experience together
Product scope, business model and experience are treated as one decision rather than three handovers. We define the core job the product performs, the flows that carry it, the data it depends on and how the venture earns. The stage produces a scoped first version, an information architecture, an interface direction and a written list of what is deliberately excluded. The exclusions matter as much as the features.
Build — engineer a product that can be operated
Engineering begins once the first version is scoped and frozen. The stack is chosen for the venture's real constraints, and environments, testing, monitoring, access control and release process are in place from the first sprint rather than retrofitted later. Work runs in short cycles against a milestone map agreed at onboarding, so progress stays visible week to week and dependencies surface while there is still room to move.
Launch — release to real users and listen closely
A launch is a starting point, not a finish line. The product goes to a defined first group of users with onboarding material, a support route and instrumentation on the flows that matter. We watch behaviour rather than opinion. The stage produces a prioritised view of what to fix, what to remove and what deserves more investment, drawn from how the product is actually used.
Scale — grow team, operations and distribution together
Scaling starts when retention and unit economics justify it, not when a launch feels successful. Distribution channels are developed, the platform is hardened for load, operating procedures are documented and hiring follows the gaps the data exposes. Growth is sequenced so support, operations and infrastructure grow alongside demand instead of trailing behind it.
Independence — give the venture its own direction
Where it fits the opportunity, a venture is set up to run as its own business with its own team, identity, roadmap and accountability. Knowledge transfer is deliberate: documentation, runbooks, architecture decisions and operating rhythm move with the team. Vedspace Ventures continues in the role agreed for that venture rather than remaining a permanent dependency.
Principles behind the process
Decisions before deliverables
Each stage exists to produce a decision, not a document. Before design or engineering begins, the work identifies the user, their current behaviour and the riskiest assumption in the idea. Research and focused prototypes are used to answer that question quickly, so effort is spent on the version of the product most likely to be worth building.
Evidence decides what happens next
No stage advances on enthusiasm alone. Each one has a defined output — a problem statement, a validation result, a scoped first version, a working release, a set of operating metrics — and that output is what qualifies a venture for the next stage. A venture can also be paused or stopped at any gate, which is a normal and useful result rather than a failure.
A connected building capability
Strategy, design, engineering, operations, growth and people development work as a connected system rather than as separate suppliers. The same team that validates an assumption helps scope the build and stays close to what happens after launch, so context is not lost between stages and decisions stay traceable to the evidence behind them.
Questions people ask about the process
What is a venture studio?
A venture studio builds companies itself rather than investing in companies other people have already started. Vedspace Ventures runs the discovery, validation, product, engineering and operating work in-house, and moves a venture forward one stage at a time as evidence accumulates.
How is a venture studio different from an agency or an accelerator?
An agency delivers a scope somebody else defined and hands it over. An accelerator supports a founding team that already exists, usually in fixed cohorts. A venture studio does the earlier work itself: choosing the problem, testing whether it is worth solving, building the first product and staying with the venture through launch and operation.
How long does it take to go from an idea to a first release?
It depends on how much is unknown rather than on how much is being built. A narrow product with a clear user and no regulatory surface moves quickly; one that needs institutional data, compliance review or hardware moves slowly. Discovery and validation are designed to be short, so the longest part of the timeline is usually the build that follows a frozen scope.
What happens if validation does not support the idea?
The venture pauses or changes shape, and that is treated as a result rather than a setback. Finding out that an assumption is wrong during a cheap test is the point of running the test. What was learned stays with the team and often reshapes the problem into one worth returning to.
What should someone bring to a first conversation?
The problem, the people who experience it and what they currently do instead. A finished plan is not required. It is more useful to arrive with a clear account of the situation and any evidence already gathered, however informal, than with a specification for a product nobody has tested yet.