Case study · API Development
Zelvyn — Math. Data. Decisions.
A mathematics, statistics, and business analytics platform providing a structured REST API and an interactive web-based API Explorer for testing analytical operations.
- TypeScript
- Next.js
- React
- PostgreSQL
- Prisma
- REST API
- OpenAPI
- Zod
- Vitest
- Vercel
About this project
Zelvyn is an API-first platform built to bring mathematics, statistics, and business analytics together in a unified developer experience. Designed around the principle of “Math. Data. Decisions.”, the platform provides structured REST API endpoints that make analytical operations accessible through consistent, well-defined requests and responses. The project consists of two independently deployable applications: a dedicated API service responsible for calculation logic and core platform functionality, and a separate web application that provides the public website, technical documentation, and an interactive API Explorer. Built with TypeScript and Next.js, Zelvyn follows a modular architecture that separates the user interface from the underlying API. The platform uses OpenAPI to describe available endpoints, Zod for request validation, and PostgreSQL with Prisma for data persistence in the API layer. Developers can explore available operations, submit JSON requests directly through the browser, and inspect structured responses containing operation results and request metadata. Supported business analytics operations include Average Order Value (AOV), alongside mathematical and statistical calculations. Zelvyn is designed to evolve into a broader analytics platform, with a focus on maintainability, clear API contracts, developer accessibility, and the ability to expand its capabilities without tightly coupling the frontend to the backend. The project reflects my approach to building practical developer tools: establish a reliable API foundation, provide a clear interface for interacting with it, and create an architecture that can support future growth.
Challenges
One of the main challenges in building Zelvyn was designing a consistent API structure across multiple analytical domains. Mathematical operations, statistical calculations, and business metrics can have different input requirements and validation rules, so the API needed a predictable request and response format without sacrificing the specific behavior of each operation. Another challenge was maintaining a clear separation between the frontend and the API. The website needed to consume the API as its source of truth rather than duplicate business logic or introduce a separate backend for functionality already owned by the API service. The interactive API Explorer introduced additional technical considerations. It needed to retrieve the live OpenAPI specification, organize endpoints by category, render the appropriate request fields, submit requests using the correct HTTP method and JSON body, and display the actual response in a readable format. Handling cross-origin restrictions and providing a reliable specification-loading mechanism were also important parts of this work. Input validation and error handling required careful attention. API consumers need clear feedback when required fields are missing, values are invalid, or an operation encounters an unsupported input. Consistent error responses and request identifiers also help make troubleshooting more practical. Finally, deploying and maintaining separate applications introduced operational considerations around configuration, authentication, API connectivity, and production verification. These challenges reinforced the importance of testing complete user flows and real API behavior rather than relying exclusively on successful builds or isolated unit tests.
Lessons learned
Building Zelvyn reinforced the importance of an API-first approach when developing a platform intended to grow across multiple analytical domains. Establishing consistent endpoint conventions, request validation, response envelopes, and error handling early makes the platform easier to maintain and extend. I also learned that separating the frontend from the API is more than an organizational choice. It creates a clearer boundary between presentation and application logic, allows each application to evolve independently, and reduces the risk of duplicating functionality across different layers. Working on the interactive API Explorer highlighted the importance of treating API documentation as part of the actual developer experience. A specification may be technically correct, but it becomes significantly more useful when developers can discover endpoints, understand their parameters, execute requests, and inspect real responses from one interface. Another important lesson was the difference between a feature appearing complete and being verified end to end. A successful HTTP response does not automatically prove that a calculation is correct, just as a successful build does not guarantee that authentication, cookies, API connectivity, or responsive layouts work correctly in production. The project also emphasized the value of explicit validation and honest system states. Missing functionality should be clearly identified rather than represented by fabricated data, and unavailable capabilities should be communicated without misleading users. Overall, Zelvyn strengthened my understanding of API design, frontend–backend boundaries, production debugging, automated testing, and the importance of building software that is understandable for both developers and end users.
Next steps
The next phase of Zelvyn focuses on strengthening reliability, completing the developer experience, and expanding the platform's analytical capabilities. **1. Complete and verify the dashboard** Review the account dashboard end to end, including session handling, protected routes, loading and error states, account information, and navigation. Dashboard features should be connected only to capabilities supported by the API, with unavailable functionality clearly identified until the required endpoints exist. **2. Expand automated API testing** Add broader validation and edge-case coverage across mathematical, statistical, and business endpoints. Tests should cover missing parameters, invalid types, boundary values, division by zero where applicable, negative values where relevant, and standardized error responses. Calculation results should be checked against independently calculated expected values. **3. Improve API documentation and developer onboarding** Continue improving the OpenAPI specification, request examples, parameter descriptions, response schemas, and error documentation. Make it easier for developers to understand how to construct requests, interpret responses, and integrate Zelvyn into their own applications. **4. Strengthen production reliability** Review production and development configuration, database separation, authentication boundaries, rate limiting, CORS policies, logging, and monitoring. Establish repeatable deployment checks and verify critical workflows against the deployed applications. **5. Develop usage visibility** Where supported by the API, introduce clearer visibility into API usage, quotas, rate limits, and request history. Any new dashboard capabilities will depend on implementing and verifying the corresponding API functionality first. **6. Expand analytical capabilities** Continue adding useful mathematical, statistical, and business analytics operations based on practical use cases. Each new operation should include explicit input requirements, validation rules, documented examples, automated tests, and predictable response formats. **7. Refine the user experience** Improve the API Explorer, responsive layouts, accessibility, empty states, and error feedback across desktop and mobile devices. The goal is to make the platform easier to explore while preserving a consistent visual identity and reliable behavior. The long-term goal is to evolve Zelvyn into a dependable, developer-friendly analytics platform where mathematical and business calculations can be discovered, tested, and integrated through a clear and consistent API.