Video summary

ALUR KERJA PEMBUATAN APLIKASI

Main summary

Key takeaways

Technology

Summary of the video (Application development workflow / SDLC)

The speaker (Eko) explains his end-to-end workflow for building applications, framed as a Software Development Life Cycle (SDLC). He notes that companies may use different stages and rules, but the core idea is to align business goals, UX, and technical implementation through documents, reviews, controlled deployment, and testing.

1) Gather initial inputs: Business requirements document + business flow

Start with a Business Requirement Document (BRD) / requirements written by product/operations/business teams (not by tech).

The BRD should include:

  • Features (what the app should do)
  • Timeline (milestones, e.g., MVP per month)
  • Business flow / process flow (customer journey, page transitions, and rules)
  • Documents/data already determined from research involving product and business/operations

Recommendation: if tech receives feature requests from non-tech teams, first request the document/flow so engineers aren’t forced to guess.

Key tech concern: avoid building “in the air” without clear data, rules, or flow (e.g., what happens when a ticket is canceled, and how different pages/processes connect).

2) UX / interaction design handed to tech

After the initial stage completes, a UX/design-like team provides artifacts to the technology team.

Typical UX outputs include:

  • Forms/screens
  • Screen-to-screen interaction flow
  • Clickable prototypes often created in tools like Adobe XD

Tech uses these artifacts to implement the intended behavior rather than inventing new interactions.

3) Technical design (convert business flow into architecture + data/services)

Tech produces a technical design document that describes the “big picture” implementation, such as:

  • Which services/APIs/modules are needed
  • Diagrams (e.g., service interaction diagrams)
  • Data model / ERD-style relationships (tables, one-to-one/one-to-many)
  • Database choices (examples mentioned: PostgreSQL and “Kadas”)
  • Inter-service communication patterns (examples mentioned: Kafka/MQ broker and messaging concepts)

Purpose

  • Prevent coding without knowing dependencies owned by other teams
  • Identify missing external services/data early
  • Clarify data exchange and performance implications before development

Benefit described: design first enables collaboration with other teams and surfaces implementation risks early (e.g., too many joins or missing dependencies).

4) Architectural review (cross-team review of technical design)

The technical design undergoes architectural review by multiple architects/teams, typically including:

  • Infrastructure architect
  • Security architect
  • Development/Software architect
  • Performance-related concerns (implied involvement of a performance/perf team)

Review focus

  • Security flaws (e.g., password hashing approach; subtitle mentions MD5, then suggests a better algorithm)
  • Performance concerns (data growth, too many joins/slow queries, normalization vs. denormalization tradeoffs)
  • Infrastructure sizing estimates (RAM/GB and traffic/data volume validation)

Outcome: the technical design is revised based on feedback before coding begins.

5) Define API specs (OpenAPI-like “endpoint specs” aligned with UX + backend)

Before full development, teams agree on API/endpoint specifications so UI and backend match.

This includes:

  • Request/response formats
  • How many endpoints are needed per screen/feature
  • Alignment on which data is returned so it matches what UX screens require

Strong emphasis: API specs must be agreed across teams early (backend, frontend, product/UX).

Reason: frontend/backend can’t independently assume different data needs. This prevents rework when the UI requires data that the backend didn’t provide (or vice versa).

API specs also cover things like:

  • Endpoint naming/parameters (e.g., productId)
  • Data composition (e.g., API returning product + logistics + banner/promo data)

Tool examples are mentioned indirectly (e.g., “Swagger”-like specification), but the key is clear early endpoint contract definition.

6) Parallel development (avoid “Waterfall waiting”)

Once specs are approved, development runs in parallel:

  • Backend implements APIs per the agreed API specs
  • Frontend implements UI using API contracts
  • The tech team builds the application components using the same agreed foundation

Goal: avoid waterfall delays where one team blocks others for weeks/months.

7) Development deployment to non-production environments + automated pipeline

The workflow includes multiple environments before production, such as:

  • Staging/testing
  • “pre-production” / “sandbox” (as referenced in subtitles)

Deployment/release is managed via an automated pipeline (CI/CD implied by subtitles mentioning CD and CI/CD-like terms).

Deploy automatically where possible to validate integration across environments before production.

8) End-to-end testing (E2E) + performance + security + bug fixes

Testing occurs in non-production environments and includes:

  • End-to-end tests (real services + full user flow verification)
  • Performance tests (e.g., response time targets like “<= 2 seconds”)
  • Security tests (e.g., checks against XSS/SQL-injection-type risks and endpoint security)

If tests fail, development continues to fix issues. The speaker highlights that parallel readiness improves the effectiveness of testing.

9) Production deployment strategies (varies by company/product risk)

After passing tests, teams deploy to production using strategies such as:

  • A/B testing
  • Canary releases / phased rollout (gradual exposure to limited users or percentages)
  • Feature rollout toggles (new features enabled for certain users)
  • Mentions blue/green conceptually

10) Maintenance / improvement (monitoring-driven optimization)

After production launch, the system needs ongoing maintenance and improvements, which may:

  • Send the process back to earlier stages when new features are needed
  • Focus on technical optimization for issues/performance degradation (not restarting entirely)

Monitoring in production

A core concept is production monitoring, tracking:

  • Data growth trends
  • Traffic levels
  • Response times
  • Error rates

Monitoring helps the team detect slowdowns/failures early and decide what to improve (algorithms, query optimization, scaling resources, etc.).

Reviews / guides / tutorials highlighted in the video

  • BRD/business flow alignment: request requirements documents first to avoid confusion
  • UX prototype to tech implementation: clicked prototypes (e.g., Adobe XD) guide UI interaction behavior
  • Technical design documentation: service diagrams + data relationships + database/messaging decisions
  • Architectural review process: security, infrastructure, and performance reviews before coding
  • API specification workflow: define endpoint request/response contracts early and align across teams
  • CI/CD + environment testing pipeline: non-production environments for deployment + E2E testing
  • Production release strategies: A/B, canary/phased rollout, blue/green conceptually
  • Monitoring-based maintenance: production monitoring to trigger performance fixes

Main speaker / sources

  • Speaker: Eko (host/讲述 of the video)
  • Referenced roles/teams: product, business/operations, UX/design, backend/frontend developers, infrastructure architects, security architects, performance/testing teams, and software architects.

Original video