AI-Prototyping: Reality Check

Speed, Strategy, Hype, Benefits, Risks

Written by Fedor Novikov, Engineering Manager at Bolt.

Introduction

In this article, AI-prototyping refers to creating a product-like artefact, either fully or mostly, using artificial intelligence, while intentionally keeping human build time to a minimum. The artefact can be a website, mobile app, service flow, dashboard, internal tool, or design mockup, or technically anything else.

A concept that once required long documents, several meetings, and multiple alignment loops can now become a clickable flow, a dashboard, a service mockup, or an “almost-MVP” in hours or days. That is the promise: shorter learning loops, clearer conversations, and earlier alignment around something people can actually use, test, and challenge [2][3]. This is the exciting part of AI in product development: it helps teams compress context.

AI is changing the product lifecycle in a simple but powerful way: it makes ideas visible earlier. But every compression has a cost.

Very few would argue against making ideas visible faster. But teams still need to follow fundamental product and project management practices to avoid drowning in endless prototypes while never delivering solutions that actually solve real problems. For instance, a polished demo can create the illusion of progress before the team has validated the problem itself, or a smooth user flow can generate confidence long before the architecture, data assumptions, security model, ownership, or transition path are properly understood.

The goal is not to sell AI prototyping as magic or dismiss it as hype. The goal is to understand what changes when the creation of artefacts becomes dramatically cheaper.

What this article examines

The main question is not whether AI can help teams move faster. It clearly can. The more useful question is not how fast AI can generate artefacts, but how teams should evaluate, validate, and evolve them afterwards.

To answer that, this article compares classical project and product lifecycle thinking [1] with AI-driven development patterns, with a specific focus on AI prototyping. We will look at where AI genuinely helps: discovery, exploration, alignment, and earlier learning. We will also examine areas where it can lead to issues, including false confidence, weak validation, governance drift, security risks, high rewrite costs, and the challenging transition from prototype to MVP and V1.

Let’s explore that through lifecycle theory, public examples, and practical delivery experience.

Key findings

The article intentionally starts with a summary to provide an AI-like experience — results first, while the research and deeper reasoning come later. The practical outcomes should be visible immediately, so the key takeaways and recommended actions are presented upfront.

The central argument is: AI-generated outcomes are not product evidence until humans validate them. Without sufficient validation, there is a significant risk of having to rebuild the solution later. AI prototyping can improve alignment and accelerate learning, but only when validation, review discipline, and transition logic keep pace with the speed of artefact creation.

Let me give an example around the central idea — what could happen to traditional product development phases when we use an AI-based approach for prototyping, MVP development, or assisted delivery. A full overview comes later in the “Applied: Product readiness comparison with and without AI” section.

Here is an artificial illustrative example of five ways to work with AI across the classical development phases (by “risk” here, we mean the possibility that the project will not be delivered on time):

This example is intentionally simplified, but it illustrates the core tradeoff. AI prototyping can absolutely help a team reach a prototype, or even an MVP-like artefact, much faster. However, the saved time often returns later as rewrite cost, hardening work, or delivery risk. In that case, the short-term speed is not a real win — it is borrowed time.

The exact numbers should not be treated as a benchmark. They are a directional model based on public sources and delivery experience. To avoid these common pitfalls, the next sections separate what AI prototyping genuinely helps with from what can be misleading, and then outline common practices that build on these ideas.

AI prototyping useful

The clearest wins show up in three patterns.

• Shared understanding, faster. A visible demo gives teams something concrete to respond to, reducing abstract debate and helping stakeholders align around a single version of the idea.
• Cheaper exploration before commitment. AI prototypes make it easier to compare several directions before the organisation locks into one path. This is especially useful when the main uncertainty is about flows, comprehension, usability, or stakeholder expectations.
• Earlier learning, not automatic readiness. The main value is not just speed; it’s learning before decisions become expensive to change. AI can help teams move faster toward a prototype or MVP [6], but it does not remove the lifecycle work needed for a trustworthy V1: validation, governance, security, integration, and ownership [1].

AI prototyping pitfalls

The most common pitfalls fall into four patterns.

• Convincing demo, weak evidence. Polished output can make unresolved problems look solved. A showcase may start to be treated as real product progress, even when it only proves that the idea can be convincingly demonstrated [2].
• Fast solution, wrong problem. AI can help teams move quickly, but speed does not prove that the problem is worth solving. Without validation, teams may only accelerate toward a better-looking mistake.
• Hidden transition cost. AI-generated prototypes often look further along than they really are. If the artefact was optimised for demo quality, later rewrites or hardening work should be expected, not treated as a surprise [7].
• Governance and security drift. Cheap artefacts can bypass ownership, review gates, evidence thresholds, and security checks while still looking credible. Weak sandboxing, real data usage, or overly permissive tools can turn a fast demo into a real organisational risk [8][9].

The answer is not to prototype less, but to prototype with stronger discipline.

Practical guardrails for AI prototyping

Up to here, the article has taken several shortcuts — jumping straight from the problem to the solution to the risks, as we’re following an AI-like experience in an article. The section below slows down and turns those quick answers into a concrete operating model. Best practices help build a stronger operating model over AI prototypes: prototype intentionally, learn early, and keep a clear boundary between an exploratory artefact and a real product.

The practices below turn the risks above into a practical operating model.

1. Start with the problem, not the prototype
   Recommended practice: Confirm that the underlying problem is worth solving before building AI functionality around it. For serious prototypes, attach a short problem statement: who it is for, what problem it addresses, what success would look like, what constraints exist, and which assumptions remain open [3][6].
   Why it matters: Fast prototyping is still a waste if the idea itself is weak. A clear problem statement keeps the team from using AI speed to rush in the wrong direction.
2. Use prototypes to explore, not to anchor too early
   Recommended practice: When the solution space is still open, compare several directions or run a short problem-framing discussion before committing to the first attractive prototype [3].
   Why it matters: AI makes the first convincing option cheap to generate, but that option can quietly become the default answer before the team has tested alternatives.
3. Assign one owner end-to-end
   Recommended practice: One person should own the story from prototype to transition decision: what was tested, what was learned, what happens next, and who needs to review it [1][4].
   Why it matters: Shared excitement does not automatically create accountability. Without a clear owner, a prototype can easily become a future misunderstanding in a nicer outfit.
4. Keep the prototype connected to a decision record
   Recommended practice: Pair important prototypes with a PRD (product requirements document), decision note, or shared feedback document. Keep a single source of truth for comments, assumptions, scope, trade-offs, and next steps [3][4].
   Why it matters: A prototype can show how something might work, but it usually does not explain why a direction was chosen or what constraints shaped the decision.
5. Label the artefact honestly and keep lifecycle boundaries clear
   Recommended practice: Call the artefact a prototype, demo, pilot, MVP, or V1 only if that label is actually true. Treat prototypes as representations of ideas, not product decisions by themselves [3][5]. Use prototypes to explore and explain; use MVPs to test value under real constraints; treat V1 as a stronger production commitment around reliability, maintainability, security, monitoring, and support [5][6].
   Why it matters: Most confusion starts when a persuasive showcase is described as product progress. A prototype can look impressive without being operationally meaningful.
6. Use safe demo conditions (no real data by default, limited permissions)
   Recommended practice: Avoid real data by default, limit permissions, and keep demo environments clearly separated from production. Do not hide manual work behind apparent automation unless the team explicitly labels it as staged or simulated [8][9][12].
   Why it matters: A demo can still create legal, privacy, trust, or commercial risk if it looks more real than it actually is.
7. Review before broad exposure
   Recommended practice: Run the right level of product, design, engineering, security, and data review before showing the artefact widely. The review should be proportional, not bureaucratic [1][4][8].
   Why it matters: Early excitement should not outrun basic sanity checks. A polished demo can influence decisions before the team has verified what it actually proves.
8. Decide the transition path early: discard, rewrite, or evolve
   Recommended practice: Be explicit about whether the prototype is expected to be discarded, rewritten, or evolved. Treat rewrite or hardening as a normal transition cost, not as an embarrassing surprise [5][7][10].
   Why it matters: Teams handle handoffs better when they don’t pretend every prototype is reusable. Many AI-generated prototypes are optimised for speed and demo quality, not for long-term durability.
9. Price the real cost and timebox the effort
   Recommended practice: Count token spend, creator time, reviewer time, stakeholder time, rewrite cost, and future support cost. Timebox prototype iterations so the team does not keep polishing a demo that should either become a validated next step or be intentionally dropped [3][7][11].
   Why it matters: Cheap generation is not the same as cheap ownership. Without limits, AI prototyping can create the feeling of progress while delaying the harder commitment decision.

One distinction deserves extra emphasis: a prototype is not an MVP. A prototype is usually a showcase or demo artefact. Its job is to make an idea visible, provoke a reaction, or test comprehension. An MVP is already a commitment to learning about the product. It has to survive real use well enough to generate validated learning under actual constraints.

An AI prototype is useful when it improves learning and decision-making. It becomes dangerous when it starts to replace decisions.

Research

This section is meant to show that the article’s main arguments about AI prototyping, prototype-to-product transition, and hidden delivery risk are grounded in established product, project, and governance thinking rather than only opinion.

While I was writing this article, Uber released a related overview of AI prototyping [3], which influenced how I framed it. Their article captures the positive side very well: It opens with a strong example of how two hours of prototyping unblocked four weeks of discussion, and then shows how AI prototypes supported exploration, alignment, and clearer MVP scoping within Uber.

I genuinely appreciate that contribution, because it gives a concrete industry example of why AI prototyping is attractive. A reader can easily stop after the first optimistic examples and walk away with a simplified conclusion: “If it worked at Uber, we can safely prototype everything with AI too.” But the harder lesson starts after the demo becomes convincing.

Uber’s article does mention important caveats: prototypes do not replace PRDs (Product Requirements Document), prototype-first is not suitable for every situation, and production still requires rigour. This article starts from the same observation but spends more time on follow-up questions that can be missed when the success story is too compelling: governance [4], prototype-to-product transition [5], security, data trust, and the distinction between a persuasive artefact and validated product progress.

The reasoning below draws on a few source families. For lifecycle and governance, it uses PMBOK [1], PRINCE2 [4], Stage-Gate [10], and Bolt PMO practices. For discovery and the prototype-versus-product boundary, it uses Lean Startup [6] and SVPG [5] frameworks. For design quality, transition cost, and operational risk, it leans on NN/g [2], Google SRE [11], Martin Fowler [7], NIST [8], FTC [12], and related public guidance. The section is organised as a small set of theses, so the evidence remains readable rather than turning into a long bibliography.

Thesis 1: Classical project lifecycles define the baseline that AI prototyping compresses

Before discussing what AI changes, it helps to name what already exists. The standard project and product lifecycle, documented across PMBOK [1], PRINCE2 [4], ISO 21502 [13], and the APM/INCOSE lifecycle guide [14], follows a recognisable sequence of phases. The terminology varies between frameworks, but the underlying shape is stable:

Initiation -> Requirements -> Design -> Development -> Testing -> Deployment -> Monitoring -> Closure

Each phase carries specific responsibilities: initiation defines the business case and authorises the work; requirements capture what the system must do; design translates requirements into architecture; development builds it; testing validates it; deployment releases it; monitoring tracks it in production; and closure formalises lessons learned and handoff.

This lifecycle has existed for decades because it solves a real coordination problem. Large teams working on complex systems need shared checkpoints, evidence gates, and clear ownership transitions. AI prototyping does not remove this lifecycle. It compresses certain phases, specifically design and development, while leaving the rest — initiation, monitoring, and closure — largely untouched.

The table below maps each lifecycle phase against what AI can realistically accelerate and what still requires human judgment. The Low / Medium / High ratings are a qualitative synthesis of NN/g [2], the Uber AI prototyping report [3], PMBOK phase definitions [1], and the author’s delivery experience. They are directional, not measured.

1. Initiation
   AI impact: Low
   What AI can do: Generate drafts, project briefs, and initial scoping documents.
   What still needs humans: Business case judgment, stakeholder alignment, and funding decisions
2. Requirements
   AI impact: Medium
   What AI can do: Explore possibilities, generate spec drafts, and identify gaps in coverage
   What still needs humans: Validation, prioritisation, constraint negotiation, and regulatory fit
3. Design
   AI impact: Medium-High
   What AI can do: Generate UI mockups, architecture drafts, and data models
   What still needs humans: Architectural trade-offs, system boundary decisions, and security posture
4. Development
   AI impact: High
   What AI can do: Code generation, rapid prototyping, boilerplate elimination
   What still needs humans: Architecture ownership, security integration, and code review discipline
5. Testing
   AI impact: Medium
   What AI can do: Generate test cases, surface patterns, and automate regression
   What still needs humans: Test strategy, edge case reasoning, acceptance criteria definition
6. Deployment
   AI impact: Low
   What AI can do: Assist with scripts, configuration, and environment setup
   What still needs humans: Infrastructure decisions, rollback planning, and release coordination
7. Monitoring
   AI impact: Low
   What AI can do: Help set up dashboards, generate alert templates
   What still needs humans: Alert logic, incident response ownership, operational accountability
8. Closure
   AI impact: None
   What AI can do: Minimal value
   What still needs humans: Lessons learned, stakeholder sign-off, knowledge transfer

The pattern is clear: AI compresses the middle of the lifecycle, where artefact generation dominates, while the phases that depend on organisational judgment, accountability, and real-world feedback remain human responsibilities. This is the baseline against which every AI prototyping claim should be measured.

Thesis 2: AI prototyping mainly changes when teams learn, not just how fast they generate artefacts

Traditional project and product frameworks, including PMBOK [1], PRINCE2 [4], and Stage-Gate [10], all assume that work moves through stages of definition, delivery, control, and handoff. Their terminology differs, but the basic idea is the same: decisions should be tied to evidence, ownership, and a clear path forward.

Get Fedor Novikov’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

AI prototyping changes this lifecycle primarily by lowering the cost of tangible exploration. Once a team can produce a visible artefact quickly, learning and alignment can happen earlier, before requirements and expectations harden. That is why the strongest upside is not interface speed by itself. It is an earlier shared understanding.

Thesis 3: Prototype, MVP, and V1 are different categories of progress

Lean Startup [6] is useful here because it frames the MVP around validated learning rather than around demo value. SVPG [5] sharpens the distinction further by separating discovery artefacts from production-oriented work. Together, these frameworks support a simpler breakdown:

• A prototype explains, explores, or tests an idea
• An MVP accepts real-world exposure to learn under actual constraints
• A V1 carries a stronger production commitment to reliability, maintainability, and support

In practice, progress on prototypes should not be counted as MVP progress. A team may learn a great deal from a prototype, but that learning does not mean the artifact is technically, operationally, or economically ready to become a product.

Thesis 4: AI-generated prototypes create understanding risk as well as speed benefits

NN/g [2] is especially useful because it documents a familiar pattern: AI prototyping tools can produce outputs that look convincing while remaining weak in actual design contexts. AI systems are good at producing plausible forms quickly, but plausible is not the same as reliable.

This creates a serious understanding risk. Teams may mistake visual coherence for problem validation — treating a convincing screen as evidence that the underlying problem is real, the solution is workable, or the system is production-ready — when in fact only the artefact is convincing. That is one of the strongest versions of what people loosely call AI slop.

The danger is not only ugly or low-quality output. The danger is output that is misleading, unvalidated, or careless, yet still persuasive enough to move decisions forward.

Design polish should be treated as a reason to review more carefully, not as a reason to lower the bar.

Thesis 5: The transition from prototype to product is where the real cost appears

Google SRE [11] is useful because it makes hidden toil visible. Martin Fowler [7] is useful because sacrificial architecture normalises the idea that rewriting can be rational when early code was optimised for learning rather than durability. Stage-Gate [10] is useful because it frames progression as something that must earn more commitment through evidence.

Taken together, these sources support a simple economic point. The cheap part of AI prototyping is generation. The expensive part is everything that follows if the organisation decides the artefact now matters: integration, security, test coverage, supportability, monitoring, data handling, ownership, and operational maintenance.

This is why the prototype-to-product transition is often the most important strategic decision in the whole workflow. The question is no longer whether the demo impressed people. The question is whether the organisation should discard it, rewrite it, or deliberately evolve it.

Thesis 6: Governance, security, and data trust remain load-bearing even when artefact creation becomes cheap

According to Bolt PMO practices, delivery discipline still depends on explicit ownership, risk visibility, communication, and clear closure. Public frameworks reach a similar conclusion through different languages. PRINCE2 [4] emphasises staged control and accountability. NIST [8] adds governance and risk framing for AI-heavy contexts. FTC [12] serves as a reminder that misleading representations can create trust and claims risk even when the underlying technology is still exploratory.

The same logic extends into security and data handling. Sandboxing is useful, but it is often misunderstood. An isolated environment can reduce exposure and limit the damage caused by mistakes, making it valuable for experiments. What it does not do is magically turn a prototype into something production-safe. Access, logging, observability, patching, tool permissions, and incident response still need to be deliberately designed. Public security guidance, such as NIST [8] and OWASP [9], is helpful here because it shows that safety is a lifecycle concern, not just a demo concern.

Using real or production-like data in a prototype often creates more risk than learning value. The moment a prototype uses real data, it inherits privacy, contractual, trust, and quality obligations that may exceed the value of the experiment. On top of that, generative systems can produce plausible outputs that appear trustworthy long before they are actually reliable. That is why exploratory work should default to synthetic, minimised, or clearly bounded data wherever possible.

An AI prototype should not be moved into production “as is” simply because it appears functional. Most such artefacts are optimised for speed, presentation, and demo success. Production systems need a different kind of quality: clear permissions, observability, resilience, support ownership, and safer data assumptions.

So, faster prototyping should not weaken governance. It should make governance more precise. Sandboxing should be treated as containment, not proof. Real data should raise the bar, not lower it. And productionization should be treated as a separate decision gate, not as an automatic continuation of prototype success.

Applied: Product readiness comparison with and without AI

Building on the research above, this section compares the product lifecycle with and without AI using an example close to a real production case. The simplified timeline below shows the core tension. AI can move teams to a prototype and even an MVP faster, but the road from MVP to V1 still contains validation, governance, integration, and transition work that no attractive demo can wish away. On the AI-prototyping path, readiness can even drop after the first successful MVP, because the team often has to rebuild, harden, or redesign the prototype before a real V1 becomes supportable.

The table below compares six realistic development scenarios from idea to V1, with risk called out for each path. Public sources provide useful directional anchors: AI-native MVP providers describe prototype or MVP delivery in days to weeks. In contrast, more conventional MVP delivery often lands in the 8–18 week range before broader production hardening [15][16][17][18]. NN/g adds an important caution: AI prototypes can be useful for early exploration and stakeholder communication, but they still require validation, refinement, and human judgment before anything ships [2].

Reading the comparison

This table should be read as a lifecycle model, not as a measured benchmark. The prototype and MVP columns show how quickly each path can create a visible artefact. The rewrite and V1 columns show where the hidden cost appears after the demo looks successful.

The figures are source-informed synthetic estimates, drawn from public references, AI-assisted research, and the author’s own delivery experience. They are not measured benchmarks and do not represent an official Bolt position. Read them as a way to compare lifecycle tradeoffs, rewrite risk, and transition cost — not as a universal delivery forecast. In the author’s view, the model is close to reality, including patterns observed in production work with the Bolt Delivery Catalog team.

Scenarios:

• Scenarios 1 and 5: based on the traditional model, production-shaped delivery.
  The traditional path and the AI-assisted copilot path differ in speed but are similar in discipline. In both cases, the work stays close to a real product shape: architecture, ownership, security, data handling, and maintainability are considered during the build, not only after the demo. Scenario 5 is often the strongest path because AI accelerates prototyping and MVP work, while human architecture keeps the rewrite tax low.
• Scenarios 2 and 3: AI-prototype-based, faster discovery, same product burden.
  AI prototype-only and serial AI prototyping both compress the front of the lifecycle. They help teams make ideas visible earlier and explore more directions before commitment. But they do not automatically shorten the harder path to V1. In scenario 2, the team still faces the same MVP and production work after the handoff. In scenario 3, the risk is different: when every direction can be demoed quickly, the team may keep exploring instead of deciding. The work feels fast, but commitment can be delayed.
• Scenarios 4 and 6: Prototyped MVP, convincing artefacts with high transition risk.
  AI-generated prototypes and AI-generated MVPs can create the strongest illusion of progress. Scenario 4 may reach an apparent MVP quickly, but the artefact is often optimised for demo paths and presentations rather than for production durability. Scenario 6 amplifies this risk: full AI generation can produce a convincing MVP-like artefact, but V1 may never arrive because the system cannot withstand production demands such as permissions, observability, resilience, support ownership, and handling real data.

The core pattern is: AI can dramatically compress the front of the lifecycle, but V1 remains a production and organisational commitment. The fastest credible path is not “use as much AI as possible.” It is “use AI where it accelerates learning, and keep human architecture where it preserves production value.”

Conclusion

So what does all of this mean? How should teams actually use AI?

There is no single “correct” answer yet. Practice is still catching up with the speed of the tools. But one thing is already clear: AI is not valuable just because it can generate something quickly. It is valuable when it helps people understand, decide, and act better.

Many teams first met AI as a text tool: summarise this, rewrite that, draft a document, prepare a plan. That was useful, but it still mostly lived in the world of words. AI prototyping moves the same question into a more powerful and more dangerous space: now AI does not only describe an idea — it can make the idea look real. And with great power comes greater responsibility.

The main risk is not AI replacing people; it is teams failing to understand what the AI helped them create. When that happens, AI stops being an accelerator and becomes a source of noise, hype, and misleading confidence. AI prototyping is one practical example of this broader pattern. Avoiding that requires a clear problem statement from the beginning. It works best when it is used to answer concrete questions: Is this direction worth exploring? Can we compare options before committing? Do stakeholders align? Is it ready to be shown to customers? In those cases, a prototype creates value by accelerating learning.

Put simply, AI prototyping lowers the cost of learning. It does not eliminate the cost of commitment. A successful prototype is not the end of the lifecycle. It is the beginning of a new decision.

In conclusion, I want to shortlist the key takeaways (the same practices described earlier): they help maintain discipline throughout AI prototyping.

1. Start with the problem, not the prototype.

2. Use prototypes to explore, not to anchor too early.

3. Assign one owner end-to-end.

4. Keep the prototype connected to a decision record.

5. Label the artefact honestly and keep lifecycle boundaries clear.

6. Use safe demo conditions (no real data by default, limited permissions).

7. Review before broad exposure.

8. Decide the transition path early: discard, rewrite, or evolve.

9. Price the real cost and timebox the effort.

Join Bolt

Grow fast, make a global impact, and help make cities for people, not cars. Explore open roles on our career page.

Links

1. Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) and the standard for project management (7th ed.). https://www.pmi.org/standards/pmbok
2. Brown, M. (n.d.). Good from afar, but far from good: AI prototyping in real design contexts. Nielsen Norman Group. https://www.nngroup.com/articles/ai-prototyping/
3. Agrawal, A., & Sharma, A. (2026, April 15). AI prototyping is changing how we build products at Uber. Uber Blog. https://www.uber.com/us/en/blog/ai-prototyping/
4. PRINCE2. (n.d.). PRINCE2 project management processes. https://www.prince2.com/uk/prince2-processes
5. Cagan, M. (n.d.). Prototypes vs products. Silicon Valley Product Group. https://www.svpg.com/prototypes-vs-products/
6. Ries, E. (2009, August 3). What is an MVP? Lean Startup Co. https://leanstartup.co/what-is-an-mvp/
7. Fowler, M. (2014, July 1). Sacrificial architecture. martinfowler.com. https://martinfowler.com/bliki/SacrificialArchitecture.html
8. Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600–1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1
9. OWASP Foundation. (2025). OWASP GenAI Security Project. https://genai.owasp.org/
10. Stage-Gate International. (n.d.). The Stage-Gate model: An overview. https://www.stage-gate.com/blog/the-stage-gate-model-an-overview/
11. Beyer, B., Murphy, N. R., Rensin, D. K., Kawahara, K., & Thorne, S. (Eds.). (2018). Eliminating toil. In The site reliability workbook. O’Reilly Media. https://sre.google/workbook/eliminating-toil
12. Atleson, M. (2023, February 27). Keep your AI claims in check. Federal Trade Commission Business Blog. https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check
13. International Organization for Standardization. (2020). Project, programme and portfolio management — Guidance on project management (ISO 21502:2020). https://www.iso.org/standard/74947.html
14. Gray, A., Richardson, K., Rooke, K., & Thornburn, T. (2017). Guide to life cycles and life cycle models (Issue 1.1). INCOSE UK & Association for Project Management. https://www.apm.org.uk/media/sg0mg1d1/guide-to-lifecycle-models.pdf