Stage 01 · Build · 12 min
Bob Builds the App
One prompt → full deployable payment app
TALKING POINT · #4
- We're building a mock credit card payment app — backend, frontend, all in one prompt.
- Notice how detailed the spec is: endpoints, card numbers, response codes, UI states. This is specs-driven development — putting the important technical details on paper upfront so Bob has everything it needs to deliver exactly what's expected.
- No back-and-forth, no misaligned deliverables.
PRESENTER NOTE · #6
In this iteration, we ask for Java 11, so we may add a stage if we want to showcase a Java modernization use case. Otherwise you can ask for a later version like Java 17+.
Prompts
Build Prompt
▼
Build a mock credit card payment processing application with:
Backend (Java 11, Spring Boot):
- REST API endpoints:
- POST /api/payments/authorize (authorize a card transaction)
- POST /api/payments/capture (capture an authorized transaction)
- POST /api/payments/refund (refund a captured transaction)
- GET /api/payments/{id} (get transaction status)
- GET /api/payments/history (list recent transactions)
- POST /admin/cache/clear (clear local cache)
- GET /actuator/health (readiness probe)
- GET /actuator/prometheus (metrics endpoint)
- Use in-memory H2 database (no external DB needed)
- Local Caffeine cache for transaction lookups
- Simulate realistic processing delays (200-500ms)
- Simulate random declines (10% of transactions)
- Return realistic response codes (approved, declined, insufficient funds, expired card)
- Use the test card numbers:
- Visa: 4263970000005262
- MasterCard: 5425230000004415
- Amex: 374101000000608
Frontend (React):
- Payment form: card number, expiry, CVV, amount
- Transaction history dashboard showing recent payments
- Status badges: Authorized (yellow), Captured (green), Declined (red), Refunded (gray)
- Simple and clean — this is for a demo, not production
Make it run with a single command: mvn spring-boot:run
Do not run the application. I will run it myself.
Also generate:
- Dockerfile — multi-stage build, distroless base, non-root user
- k8s/deployment.yaml — OpenShift deployment manifest with placeholder values:
- Image: image-registry.openshift-image-registry.svc:5000/${NAMESPACE}/payment-app:${IMAGE_TAG}
- Namespace: ${NAMESPACE}
- 3 replicas, resource limits, readiness/liveness probes
- PodDisruptionBudget (max 1 unavailable)
- Service and Route
Use placeholder values only — real cluster values will be injected at deploy time.
Use the following folder structure:
```
payment-app/
├── src/
│ └── main/
│ ├── java/com/demo/payment/
│ │ ├── controller/
│ │ ├── service/
│ │ ├── model/
│ │ └── config/
│ └── resources/
│ ├── static/ ← React frontend
│ └── application.properties
├── pom.xml
├── Dockerfile
├── k8s/
│ └── deployment.yaml ← OpenShift manifest with placeholder values
└── README.md
```
---
## Lessons Learnt
1. **`GenerationType.UUID` requires JPA 3.x** — Spring Boot 2.7 ships with JPA 2.x (Hibernate 5), which does not support `GenerationType.UUID`. Use `UUID.randomUUID()` in a `@PrePersist` hook instead, or upgrade to Spring Boot 3.x.
2. **Lombok requires annotation processing to be active at compile time** — When Lombok is on the classpath but the compiler's annotation processor isn't wired correctly (e.g., missing `-proc:full` flag or IDE misconfiguration), all generated methods (`getters`, `setters`, `builder`, `log`) are invisible to `javac` and produce "cannot find symbol" errors. For a zero-friction demo, replacing Lombok with explicit getters/setters and a hand-written builder is more portable and avoids the dependency entirely.
TIP · #35
The cost of this build is ~0.31 bobcoins.
TALKING POINT · #5
As Bob generates — watch it first produce a detailed to-do list, breaking down the entire build plan before writing a single line of code. Depending on your allowed actions settings, Bob may pause and ask for your approval before executing certain steps — such as creating files or running commands. This gives you full control over what Bob does and when.When it's done building the app, Bob will generate a
README.md detailing everything that was implemented. It will also provide a clear handoff message so you know exactly what to do next.Notice that Bob didn't just build the application — it also generated the Dockerfile and the OpenShift deployment manifest in
k8s/deployment.yaml. One prompt, and you have everything needed to containerize and deploy the app in production.
Bob Produces
src/main/java/... — Spring Boot REST API (controllers, services, models)
src/main/resources/static/ — React frontend (payment form + history dashboard)
pom.xml — Maven dependencies (Spring Boot, H2, Caffeine, Actuator)
application.properties — H2 config, cache settings, actuator exposure
Dockerfile — multi-stage build, distroless base, non-root user
k8s/deployment.yaml — OpenShift manifest with placeholder values (image, namespace, registry)
README.md — how to build and run
PRESENTER NOTE · #7
In a terminal, run:cd payment-appmvn spring-boot:runThis will start the app on
localhost:8080. Once it's up, open the browser and showcase the UI is live.How to fill the form:
• Card Number: use one of the test cards — e.g. Visa
4263970000005262• Expiry: any future date, e.g.
12/26• CVV: any 3-digit number, e.g.
123• Amount: any value, e.g.
99.99Hit Authorize and watch the transaction appear in the history dashboard. The expected outcome is one of: Authorized (yellow), Captured (green), Declined (red), or Refunded (gray) — with a ~10% chance of a decline to simulate real-world behavior.
This confirms the UI is talking to the backend — Bob didn't just generate code, it generated a working application.
TIP · #36
If you run into any issues bringing up the app, just ask Bob to troubleshoot. Select the error message in the terminal, right-click → IBM Bob → Add terminal content to context or Fix this command — Bob will diagnose and fix the problem instantly. This itself is a great live demo moment.