This checklist covers the requirements most likely to surprise first-time founders. Every item comes from Apple's or Google's official documentation, checked on October 27, 2026. Store rules change often, so confirm each one with your developers before you submit.

Apple App Store

1. A privacy policy, in two places

Apple's App Review Guidelines say: "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." Write the policy before launch week, not during it.

2. In-app account deletion

If people can create an account in your app, Apple requires a way to delete it inside the app. Guideline 5.1.1(v) states: "If your app supports account creation, you must also offer account deletion within the app." Plan the screen and the backend process for this from the start.

3. Don't force a login without a reason

The same guideline says: "If your app doesn't include significant account-based features, let people use it without a login." If users can browse or try features before signing up, design for that.

4. App privacy details (the "privacy label")

In App Store Connect, you describe what data your app collects and how it is used. Apple notes that this includes "the practices of third-party partners whose code you integrate into your app," such as analytics and advertising tools. This information is "required to submit new apps and app updates." Ask your developers for a list of every software development kit (SDK) in the app.

5. Built with the current tools

Since April 28, 2026, apps uploaded to App Store Connect "must be built with Xcode 26 or later using an SDK for iOS 26." Any agency building for you should already work with the current version.

Google Play

6. The Data safety form

Google requires: "All developers that have an app published on Google Play must complete the Data safety form." Even apps that collect no user data "must complete this form and provide a link to their privacy policy." The form must also cover data handled by third-party libraries and SDKs, and must "remain accurate and complete at all times."

7. Closed testing for new personal accounts

This rule catches many solo founders. If your Google Play developer account is a personal account created after November 13, 2023, you must run a closed test with at least 12 testers who stay opted in for at least 14 consecutive days before you can publish to production. Line up your testers early. Testers who leave before day 14 don't count, and rejoining restarts their count.

8. Target a recent Android version

Since August 31, 2026, new apps and app updates on Google Play must target Android 16 (API level 36) or higher. Your developers set this in the app's build settings. It also means every app needs regular updates as these requirements rise each year.

Before you press submit

• Privacy policy published at a public URL and linked inside the app.
• Account deletion works inside the app if accounts exist.
• A list of every third-party SDK and the data each one collects.
• App privacy details (Apple) and Data safety form (Google) completed from that list.
• Test accounts and clear notes ready for the store reviewers if your app requires a login.
• For new personal Google Play accounts: 12 testers lined up for a 14-day closed test.
• Build settings meet current Xcode and Android target requirements.

Plan your timeline around review

Store requirements add work that is easy to underestimate: legal text, privacy forms, a deletion flow and, on Google Play, a two-week closed test for new personal accounts. Build them into the project plan from the start, and ask your agency who is responsible for each item on the checklist.

The bottom line

Most launch delays come from missing paperwork and policy requirements, not code. Treat privacy, account deletion, store forms and testing as part of the product, and your first submission is far more likely to go through smoothly.

Sources

• Apple: App Store Review Guidelines
• Apple: App privacy details on the App Store
• Apple: Upcoming requirements
• Google Play Console Help: Data safety section
• Google Play Console Help: Testing requirements for new personal developer accounts
• Android Developers: Target API level requirements

This guide explains the difference in plain language, using official documentation from React, Next.js, Google and web.dev.

The one idea you need: where the page is built

Every web page has to be turned into HTML, the code a browser displays. The key question is where that happens.

• In the browser (client-side rendering). The server sends a nearly empty page plus JavaScript, and the visitor's browser builds the content. This is how a plain React app works by default.
• On the server or ahead of time (server rendering or prerendering). The server sends a page that already contains the content. The browser can show it immediately, then JavaScript adds interactivity.

Next.js supports both. In its App Router, Server Components are the default. According to the Next.js glossary, they "render on the server, can fetch data directly, and don't add to the client JavaScript bundle." Next.js also prerenders pages by default when they do not depend on request-specific data, so the result "can be cached and served from a CDN."

What React itself recommends

React's own documentation says: "If you want to build a new app or website with React, we recommend starting with a framework." It names Next.js's App Router as one option.

Building from scratch with Vite, Parcel or Rsbuild is still supported. The React docs note that this "gives you more flexibility, but does require that you make choices on which tools to use for routing, data fetching, and other common usage patterns."

How Google reads JavaScript pages

Google can index pages that are built with JavaScript. Its documentation explains that it processes JavaScript web apps in three phases: crawling, rendering and indexing. During rendering, a headless version of the Chromium browser runs the page's JavaScript.

Even so, Google's guidance adds: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers." It also notes that not all bots can run JavaScript. That matters for link previews in messaging apps and social networks, and for other search engines.

How speed is measured

Google's Core Web Vitals are the standard measures of page experience. According to web.dev, good targets are:

• Largest Contentful Paint (LCP) within 2.5 seconds: how quickly the main content appears.
• Interaction to Next Paint (INP) of 200 milliseconds or less: how quickly the page responds to taps and clicks.
• Cumulative Layout Shift (CLS) of 0.1 or less: how much the layout jumps around while loading.

web.dev recommends measuring these at the 75th percentile of page loads, separately for mobile and desktop. That means three out of four visits should meet the target.

Sending ready-made HTML, as server rendering and prerendering do, usually helps the main content appear sooner. Sending less JavaScript can also help pages respond faster. The actual results still depend on how the site is built, so measure them.

Which should you choose?

Choose Next.js (or a similar framework) if:

• Search traffic matters: a marketing site, blog, marketplace listings or public product pages.
• You want link previews to work reliably when pages are shared.
• You want server rendering, prerendering and routing to come built in.

A plain React app can be fine if:

• The product sits behind a login, such as a dashboard or internal tool, where search engines never see the content.
• Your team has a strong reason to choose and maintain its own routing and data tools.

Many startups use both: a framework for public pages and a client-rendered app behind the login.

Questions to ask your developers

• Which of our pages need to be found in search, and how will they be rendered?
• What are our Core Web Vitals on mobile today, and what is the target?
• How much JavaScript does the home page send, and can we reduce it?
• If we start with a plain React app, what would it take to add server rendering later?

The bottom line

For public pages that need to rank and load fast, starting with a framework such as Next.js follows both React's and Google's guidance. For logged-in apps where search does not matter, a plain React app is a reasonable choice. Either way, decide based on which pages must be found and how fast they must feel, and measure the result with Core Web Vitals.

Sources

• React: Creating a React App
• Next.js Glossary
• Google Search Central: Understand the JavaScript SEO basics
• web.dev: Web Vitals

This guide explains the 2025 list in plain language and highlights what a founder should ask the team building the feature.

The 2025 list at a glance

1. LLM01: Prompt Injection. User input changes how the model behaves.
2. LLM02: Sensitive Information Disclosure. The system reveals data it should not.
3. LLM03: Supply Chain. Risks from third-party models, data and components.
4. LLM04: Data and Model Poisoning. Training or fine-tuning data is tampered with.
5. LLM05: Improper Output Handling. Model output is used without being checked.
6. LLM06: Excessive Agency. The AI is given more power than it needs.
7. LLM07: System Prompt Leakage. The hidden instructions behind the AI are exposed.
8. LLM08: Vector and Embedding Weaknesses. Risks in the search systems that feed the model your data.
9. LLM09: Misinformation. The model produces false or misleading content.
10. LLM10: Unbounded Consumption. The system uses resources, and money, without limits.

You do not need to master all ten before launch. For most startups, four of them deserve attention first.

1. Prompt injection: the risk every AI feature has

OWASP defines it this way: "A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways." A user might type instructions that make your support bot ignore its rules, or hide instructions inside a document the AI is asked to summarize.

OWASP's recommended defenses include:

• Giving the model "specific instructions about the model's role, capabilities, and limitations."
• Restricting "the model's access privileges to the minimum necessary."
• Adding "human-in-the-loop controls for privileged operations."

Ask your team: What happens if a user tells the assistant to ignore its instructions? Have we tested it?

2. Excessive agency: when the AI can do too much

This risk matters most for AI agents that can send emails, update records or make purchases. OWASP describes it as a weakness that "enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM." It names three root causes: "excessive functionality," "excessive permissions" and "excessive autonomy."

The key mitigation is to keep the final decision outside the model: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not."

Ask your team: Which actions can the AI take on its own, and which need a person to approve them?

3. Sensitive information disclosure

An AI feature connected to your data can repeat that data to the wrong person. That includes customer records, internal documents or another user's conversation. The fix is mostly ordinary security done carefully: only give the model data the current user is allowed to see, and avoid putting secrets in prompts.

Ask your team: If two customers use the assistant, can one ever see the other's data?

4. Unbounded consumption: the risk to your bill

AI providers usually charge per use. OWASP describes a "Denial of Wallet" attack, where attackers "exploit the cost-per-use model of cloud-based AI services" to run up costs. Its recommended control is simple: "Apply rate limiting and user quotas."

Ask your team: What stops one user, or one script, from sending thousands of requests an hour?

What about the other six?

The remaining risks matter more as your product grows:

• Supply chain and data and model poisoning matter when you use third-party models or train on outside data.
• Improper output handling matters when AI output is inserted into web pages, database queries or code.
• System prompt leakage is a reminder never to put passwords or secret business rules in the instructions you give the model.
• Vector and embedding weaknesses apply when the AI searches your documents to answer questions.
• Misinformation is why AI answers about your product should be grounded in your own content and checked.

A short pre-launch checklist

• The AI can only reach data the current user is allowed to see.
• Sensitive actions need human approval or checks outside the model.
• Inputs are rate-limited and spending has alerts and caps.
• The team has tried to break the feature with hostile prompts.
• AI output is validated before it is shown in a page or used in a query.

The bottom line

AI features fail in new ways, but the defenses are familiar: least privilege, human approval for risky actions, input limits and testing. Use the OWASP list as a shared language with your developers, and ask the questions above before launch, not after an incident.

Sources

• OWASP Top 10 for LLM Applications 2025
• OWASP, LLM01:2025 Prompt Injection
• OWASP, LLM06:2025 Excessive Agency
• OWASP, LLM10:2025 Unbounded Consumption

This guide is based mainly on Blockchain Technology Overview (NISTIR 8202), a report published in October 2018 by the US National Institute of Standards and Technology (NIST), a government agency that writes widely used technology standards.

What a blockchain is

NIST describes a blockchain as "essentially a decentralized ledger that maintains transaction records on many computers simultaneously." A ledger is a record of transactions. "Decentralized" means no single company holds the master copy. Many participants keep copies, and the network has rules for agreeing which new records get added.

The report's overall message is cautious. In its executive summary, NIST says blockchain "is not magical; it will not solve all problems." When the report was released, co-author Dylan Yaga, a NIST computer scientist, put it more directly: "We wrote with the perspective that you shouldn't use it if it's not necessary."

Start with the problem, not the technology

NIST recommends that organizations ask "how could blockchain technology potentially benefit us?" rather than "how can we make our problem fit into the blockchain technology paradigm?"

In practice, that means writing down the problem first. For example: "Five companies need to share shipment records, none of them trusts the others to run the database, and every party needs to see the same history." That is a very different starting point from "We want to use blockchain."

Questions to ask before you commit

The questions below are a practical checklist drawn from the issues NIST discusses. If you answer "no" to most of them, a regular database is probably the better choice.

1. Do several separate organizations need to write to the same records?

If only your company writes the data, a standard database that you control is simpler, faster and cheaper to run.

2. Is there a reason those organizations cannot simply trust one party to run the database?

If everyone is happy for one company or a neutral provider to host the data, you may not need a decentralized ledger at all.

3. Is it acceptable that records, once written, are very hard to change or delete?

That property is useful for audit trails. It is a problem if you store personal data that people may ask you to correct or delete. NIST also discusses immutability in its section on limitations and misconceptions: a blockchain's history is hard to change, but that is not the same as impossible.

4. Does the data need to be visible to everyone, or only to approved participants?

NIST separates permissionless blockchains, which anyone can join, from permissioned blockchains, where an owner controls who can add records and, often, who can read them. Many business uses need the permissioned kind, which changes the trust model and the cost.

5. Can your product live with slower and more expensive writes than a normal database?

The computers that maintain the ledger have to process and agree on new records. For high-volume, low-latency features such as chat, analytics or real-time dashboards, that overhead is hard to justify.

A common misconception: "no trust needed"

A popular claim is that blockchain removes the need for trust. The NIST report covers "no trust" in its section on limitations and misconceptions. As Yaga explained: "You do need trust," just "not a trusted third party, like a bank." Participants still need to trust the software, the rules of the network, the people who run the nodes and, in permissioned systems, the owner who grants access.

Where blockchain can make sense

When NIST released the report, it named banking, supply chain management and insurance transaction tracking as possible areas of use. The common thread is several parties who need a shared, verifiable history of transactions without handing control to one of them.

Even in those areas, a pilot should prove that the shared ledger solves a real coordination problem better than a shared database with good access controls and audit logs.

What to ask a development agency

If an agency proposes blockchain for your product, ask:

• Which specific problem does the blockchain solve that a database cannot?
• Will it be permissioned or permissionless, and who runs the nodes?
• How will we handle personal data that users may ask us to delete?
• What are the expected transaction costs and speeds at our planned usage?
• What does a pilot look like, and how will we measure whether it worked?

The bottom line

Blockchain is a tool for a specific kind of problem: several parties who need to share and verify records without one trusted operator. For most early-stage products, a well-designed database is faster to build, cheaper to run and easier to change. Start with the problem, use the questions above, and adopt blockchain only if it clearly earns its place.

Sources

• NIST, Blockchain Technology Overview (NISTIR 8202), October 2018
• NIST news release, "NIST Report on Blockchain Technology Aims to Go Beyond the Hype", January 24, 2018

Enter CloudGuard AI — an open-source project that does exactly that, while providing a real-world authentication microservice to play with.

Check out the project on GitHub

What is CloudGuard AI?

At its core, CloudGuard AI is a Node.js/Express authentication service backed by PostgreSQL. But unlike typical beginner projects, it comes with:

• Containerization: Docker and Docker Compose for easy deployment.

• Monitoring: Prometheus metrics, Grafana dashboards.

• Logging & Alerting: Winston logs, Loki log storage, and Alertmanager alerts.

• Security: JWT auth, hashed passwords, npm audit, Gitleaks, Trivy scans.

• CI/CD: GitHub Actions workflows for automated testing and deployment.

Think of it as a real-world platform “boilerplate” that any DevOps, SRE, or cloud engineer would recognize.

Features Overview

The current phase focuses on the auth-service with these endpoints:

POST /register   → Register a new user
POST /login      → Authenticate and get JWT
GET /profile     → Protected route, requires Bearer token
GET /health      → Health check
GET /ready       → Readiness check
GET /metrics     → Prometheus metrics
GET /api-docs    → Swagger/OpenAPI documentation

How it works

• Register: Validates input, hashes the password with bcrypt, stores the user in PostgreSQL.

• Login: Validates credentials, compares the password hash, returns a JWT.

• Profile: Verifies JWT and returns user profile.

The Prisma schema currently includes a single User model:

model User {
  id          String   @id @default(uuid())
  name        String
  email       String   @unique
  passwordHash String
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
}

Tech Stack

• Backend: Node.js, Express, Prisma, PostgreSQL

• Authentication: JWT, bcryptjs

• Testing: Jest, Supertest

• Containerization & Platform: Docker, Docker Compose

• Monitoring & Logging: Prometheus, Grafana, Loki, Promtail, Alertmanager

• Security Scans: npm audit, Gitleaks, Semgrep, Trivy

• CI/CD: GitHub Actions

This combination makes it more than just an API — it’s a full production-like platform.

Running the Platform Locally

You can spin up the entire platform (auth service + monitoring + logging) using Docker Compose:

docker compose -f docker/docker-compose.auth.yml up -d --build

Services included:

• PostgreSQL (5432)

• Auth service (5001)

• Prometheus (9090)

• Grafana (3000)

• Loki (3100)

• Alertmanager (9093)

Endpoints to explore:

• API docs: http://localhost:5001/api-docs

• Health: http://localhost:5001/health

• Prometheus metrics: http://localhost:5001/metrics

• Grafana dashboards: http://localhost:3000

Why CloudGuard AI is Portfolio-Worthy

Most beginner projects end with a simple Express API. CloudGuard AI demonstrates real-world production concepts:

Build → Test → Containerize → Monitor → Log → Scan → Deploy → Alert → Rollback

Adding monitoring, alerting, and security scans shows recruiters and hiring managers that you understand how apps run in production, not just how to write endpoints.

The “AI” Part — Future Plans

Despite the name, the current version doesn’t include AI. The README mentions planned AIOps features such as:

• Incident assistant using AI to suggest fixes

• Automated cloud configuration checks

• Integration with Terraform/Kubernetes/Argo CD

For now, it’s best viewed as a DevSecOps/DevOps authentication platform with future AI aspirations.

Conclusion

If you’re looking to level up your backend and DevOps skills, CloudGuard AI is a fantastic learning resource. It combines Node.js development, containerization, monitoring, logging, security, and CI/CD into a single cohesive project.

It’s perfect for:

• DevOps / SRE learning

• Portfolio projects

• Practicing secure and monitored backend design

• Experimenting with mini cloud-native platforms

Explore the project and start running it locally — you’ll get a feel for how production-ready applications are built from scratch.

Check out CloudGuard AI on GitHub