Skip to main content

How to Ship a Real App on QuikDB (and Win #BuildQuikChallenge)

You have an idea. You want to build something real. You want to deploy it. And maybe you want to win N200,000 doing it.

The #BuildQuik Challenge is QuikDB's quarterly developer build challenge. Every quarter, we challenge developers to ship a working app on QuikDB Compute in 2 weeks. The best projects win cash prizes and get showcased at a live finale event.

This guide walks you through shipping a functional app on QuikDB Compute, from zero to live URL. No fluff. Just the steps. Whether you are joining Season 1 or a future edition, the process is the same.

What is QuikDB Compute​

QuikDB Compute is a deployment platform. You push code, it runs on decentralized community-powered nodes. No servers to configure, no AWS console, no Docker headaches.

It supports Node.js, Python, Go, Ruby, Java, .NET, PHP, Rust, Deno, Bun, static sites, and custom Dockerfiles. If you can build it, QuikDB can run it.

Step 1: Pick Something Real to Build​

The #BuildQuikChallenge judges care about usefulness. That is 30% of your score. So build something people would actually use.

Good ideas:

  • A URL shortener with analytics
  • An AI-powered resume reviewer
  • A budget tracker with charts
  • A Discord bot with a web dashboard
  • A developer tool (API monitor, log viewer, status page)
  • A simple CRM or invoice generator

Bad ideas:

  • A portfolio site (not eligible)
  • A landing page with no backend
  • A clone of something that already exists with nothing new added

The minimum bar: your app must have at least one functional feature, it must be live on QuikDB at judging time, and you must post about it on X with #BuildQuik.

Step 2: Build Your App Locally​

Pick your stack. QuikDB auto-detects all of these:

StackExample
Next.jsnpx create-next-app@latest my-app
Expressnpm init -y && npm install express
FastAPIpip install fastapi uvicorn
Flaskpip install flask
Gogo mod init myapp
Static HTMLJust create an index.html

Build it. Get it running locally. Make sure npm start (or your equivalent) actually works.

Key rule: if it does not run on your machine, it will not run on QuikDB. Fix your app locally first.

Step 3: Push Your Code to GitHub​

QuikDB deploys from GitHub (or GitLab). Your code needs to be in a repository.

git init
git add .
git commit -m "initial commit"
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO.git
git push -u origin main

Make sure your repo includes:

  • package.json (for Node.js) or requirements.txt (for Python) or go.mod (for Go)
  • A working build and start command
  • No hardcoded secrets (use environment variables instead)

Step 4: Sign Up on QuikDB Compute​

Go to compute.quikdb.com and create an account. The Hobby plan is $5/month and gives you:

  • 3 containers
  • 0.5 vCPU and 512 MB RAM per container
  • 2 GB storage per container
  • 5 builds per day
  • A free *.quikdb.net URL

That is more than enough to ship and demo a real app.

Step 5: Connect Your GitHub Account​

From the dashboard, click Connect Repository and authorize GitHub. QuikDB needs read access to clone your code during builds.

Once connected, you will see a list of your repositories.

Step 6: Select Your Repository and Deploy​

  1. Pick the repo you just pushed
  2. Choose the branch (usually main)
  3. QuikDB auto-detects your stack and fills in the build settings

You will see:

  • Runtime — auto-detected (e.g., Node.js, Python)
  • Build command — e.g., npm install && npm run build
  • Start command — e.g., npm start
  • Port — defaults to 3000

If something looks wrong, edit it. Then click Deploy.

QuikDB will:

  1. Select healthy nodes from the network
  2. Clone your repo on the selected node
  3. Build a container from your code
  4. Start the container and run health checks
  5. Route traffic to your app once it is healthy

You can watch the build logs in real time.

Step 7: Add Environment Variables (If Needed)​

If your app uses a database URL, API key, or any secret, do not hardcode it.

Go to your deployment detail page, click the Environment tab, and add your variables. You can add them one at a time or bulk import from a .env file.

All variables are encrypted at rest with AES-256-GCM. Variables with SECRET, KEY, TOKEN, PASSWORD, or API_KEY in the name are automatically masked in the UI.

After adding variables, click Redeploy to apply them.

Step 8: (Optional) Add a quikdb.json Config File​

If you want more control, add a quikdb.json file to your repo root:

{
  "name": "my-challenge-app",
  "runtime": "nodejs",
  "buildCommand": "npm install && npm run build",
  "startCommand": "npm start",
  "port": 3000,
  "resources": {
    "cpuCores": 0.5,
    "ram": 512,
    "storage": 2000
  }
}

This overrides auto-detection and gives you explicit control over how your app is built and run. This is optional. QuikDB handles it automatically if you skip this.

Step 9: Verify Your App is Live​

Once the deployment state shows live, click the URL (something like your-app.quikdb.net) and check that your app works.

If the deployment failed, check the build logs. Common issues:

  • Missing dependencies in package.json or requirements.txt
  • Build command fails (test it locally first with the exact same command)
  • App not listening on the correct port (use $PORT or 3000)
  • Missing environment variables

Fix the issue, push to GitHub, and click Redeploy. QuikDB uses blue-green deployment, so redeployments have zero downtime.

Step 10: Push Updates​

Every time you push to your branch, you can redeploy from the dashboard. QuikDB starts a new container alongside the old one, checks that the new one is healthy, then switches traffic over. No downtime.

You can also roll back to any previous deployment instantly from the deployment history tab.

How to Actually Win​

The judging criteria:

CriteriaWeightWhat judges look for
Usefulness30%Would real people use this?
Completeness25%Is it functional end-to-end? Not just a landing page?
Technical quality20%Clean code, proper deployment, handles edge cases
Creativity15%Original idea or clever approach
Presentation10%Demo quality, README, public post

Winning tips:

  1. Solve a real problem. Even a small one. A working budget tracker beats a half-finished AI agent.
  2. Make it complete. One finished feature is better than five broken ones. Users should be able to sign up, do the thing, and see the result.
  3. Write a good README. Explain what your app does, how to use it, and include a screenshot. Judges review a lot of projects. Make yours easy to understand.
  4. Record a 2-minute demo video. Screen record yourself using the app. Show what it does, not how you built it.
  5. Post on X with #BuildQuik. This is required for eligibility and counts toward your presentation score.

Quick Reference (Season 1)​

WhatWhere
Sign upcompute.quikdb.com
Docsdocs.quikdb.com
Events pagequikdb.com/events
SupportDiscord #build-quik-challenge channel
Submit your projectOpen a GitHub Issue on quikdb/buildquik
DeadlineFriday June 5, 11:59 PM WAT
Live finaleSaturday June 6, AfriLab, Lagos
Next seasonQ3 2026 (dates announced after Season 1 finale)

Example: Deploy a Next.js App in 5 Minutes​

npx create-next-app@latest my-quikdb-app
cd my-quikdb-app
git init && git add . && git commit -m "init"
git remote add origin https://github.com/you/my-quikdb-app.git
git push -u origin main

Then on compute.quikdb.com:

  1. Connect GitHub
  2. Select my-quikdb-app
  3. Click Deploy
  4. Wait for build logs to finish
  5. Visit your *.quikdb.net URL

That is it. Your app is live on the internet.

Example: Deploy a FastAPI App​

mkdir my-api && cd my-api
python -m venv venv && source venv/bin/activate
pip install fastapi uvicorn

Create main.py:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "shipped on QuikDB"}

@app.get("/health")
def health():
    return {"status": "ok"}

Create requirements.txt:

fastapi
uvicorn

Push to GitHub, then deploy on QuikDB. It auto-detects Python and sets the start command to uvicorn main:app --host 0.0.0.0 --port $PORT.

This is not required. But if you want to stand out from the pack, submit a shipping plan alongside your deployed app. Judges notice participants who think beyond code.

A shipping plan shows you did not just build something — you thought about why it exists, who it is for, and how it survives after the challenge ends.

What to Include​

Your shipping plan is a short document (1-3 pages, Google Doc or Notion is fine) covering these sections:

1. Idea Validation​

Before you wrote a single line of code, how did you decide this was worth building?

  • What problem does your app solve? One sentence. Be specific.
  • Who has this problem? Describe your target user. Not "everyone." A real person.
  • How do people solve this problem today? What are they currently using? What is broken about it?
  • Did you talk to anyone? Even one conversation with a potential user counts. If you posted in a Discord or subreddit and got responses, that counts too.

Tools to make this easier:

  • Google Forms — create a quick 3-question survey and share it in relevant communities
  • X / Reddit / Discord — post your idea and ask "would you use this?" before building
  • ChatGPT / Claude — use AI to stress-test your idea. Ask it to poke holes in your concept

You do not need 50 interviews. Even 3-5 quick conversations or a poll with 10 responses shows you validated before building.

2. Target Audience​

Who specifically are you building for?

  • Describe one ideal user. Example: "A freelance designer in Lagos who tracks invoices in a spreadsheet and forgets to follow up on payments."
  • Where do they hang out online? X, Discord, Reddit, WhatsApp groups?
  • What would make them switch from their current solution to yours?

Tools:

  • Notion or Google Docs — write a simple one-paragraph user persona
  • X Search — search for people complaining about the problem you are solving. Screenshot the tweets.

3. Tech Stack Rationale​

Explain why you chose your stack, not just what it is.

  • Why this framework? (e.g., "Next.js because I need SSR for SEO" or "Express because I only need a REST API")
  • Why this database? (e.g., "SQLite because it is simple and I do not need scale yet" or "MongoDB because my data is unstructured")
  • Any tradeoffs you made? (e.g., "I chose Tailwind over custom CSS to move faster, even though the design is less unique")

This does not need to be long. 3-5 bullet points showing you made intentional decisions.

4. MVP Scope​

What did you build, and more importantly, what did you not build?

  • Core feature: The one thing your app does. The reason someone would open it.
  • Cut features: What you decided to skip for now and why. This shows discipline.
  • What would v2 look like? If you had another month, what would you add?

Tools:

  • Linear or GitHub Issues — track your features as issues. Link to your board in your submission.
  • A simple table works too:
FeatureStatusPriority
User authDoneMust have
Invoice generatorDoneMust have
PDF exportDoneNice to have
Recurring invoicesSkippedv2
Stripe paymentsSkippedv2

5. Testing​

Did you test your app before submitting?

  • Manual testing: Did you click through every flow yourself? Did you try breaking it with bad inputs?
  • Automated tests: Even one test file shows you care about quality. You do not need 100% coverage.
  • Edge cases: What happens when the user enters nothing? What happens when the API is slow?

Tools:

  • Jest (Node.js), Pytest (Python), or Go's built-in testing — even 3-5 basic tests help
  • Postman or Thunder Client — test your API endpoints manually and screenshot the results
  • Lighthouse (built into Chrome DevTools) — run a quick audit on your deployed app and include the score

6. Deployment and Monitoring​

You are already deploying on QuikDB. But show that you thought about reliability:

  • How do you know your app is healthy? Do you have a /health endpoint?
  • What happens if it crashes? QuikDB auto-restarts containers, but did you add error handling?
  • Environment variables: Are your secrets properly stored in QuikDB's encrypted env vars, not hardcoded?

Add a health endpoint to your app. It takes 30 seconds:

Node.js/Express:

app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: new Date().toISOString() });
});

Python/FastAPI:

@app.get("/health")
def health():
    return {"status": "ok"}

Go:

http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    w.Write([]byte(`{"status":"ok"}`))
})

7. Launch Plan​

Even if your app is small, how would you get your first 10 users?

  • Post on X with #BuildQuik (you are already doing this)
  • Share in relevant Discord servers or WhatsApp groups
  • Post on Reddit in a relevant subreddit
  • Ask 3 friends to try it and give feedback
  • Write a short thread on X explaining what you built and why

Tools:

  • Loom — record a 60-second demo video and share the link everywhere
  • Canva — make a simple social media graphic for your launch post
  • Twitter/X Analytics — track impressions on your #BuildQuik post

How to Submit Your Shipping Plan​

Add it to your GitHub Issue submission as a link. Any of these formats work:

FormatToolHow
Google Docdocs.google.comWrite it, set sharing to "anyone with link", paste the URL
Notion pagenotion.soWrite it, click Share > "Share to web", paste the URL
Markdown in your repoGitHubAdd a SHIPPING_PLAN.md file to your repo root
PDFAny toolUpload to Google Drive or your repo

Keep it short. 1-3 pages maximum. Judges will skim, not study. Use bullet points, not paragraphs.

Why Bother?​

This is optional. You can win without it. But here is why it matters:

  1. Presentation is 10% of your score. A shipping plan elevates your presentation above everyone who just submitted a repo link.
  2. It shows maturity. Anyone can write code. Fewer people think about users, tradeoffs, and what comes next.
  3. It makes your demo video better. When you have a plan written down, your 2-minute demo becomes sharper because you know exactly what story to tell.
  4. It is a real-world skill. Every startup, every job, every serious project requires this thinking. Practice it now.

The participants who submit a shipping plan will look like builders. The ones who skip it will look like coders. Judges know the difference.

Ship something real. Deploy it on QuikDB. Post it with #BuildQuik. That is how you win.

Missed this season? The #BuildQuik Challenge runs every quarter. Follow @quikdb_online on X to get notified when the next season opens.