A platform to close the urban gardening knowledge gap in Brazil
The Client
Personal capstone project for a Postgraduate degree in Software Engineering at PUC Minas Virtual. Full ownership of problem framing, product design, and implementation — with no external client or team.
The Problem
Urban gardening is one of the most accessible climate adaptation strategies, yet in Brazil there are very few apps supporting everyday people in planting and maintaining gardens. The main barrier is a lack of accessible technical knowledge about species, planting times, and maintenance.
Design Objectives
- Help users design and plan their own gardens
- Provide an accessible, education-oriented experience for gardeners from beginner to professional
- Create a consistent visual identity and user flows across the application
- Ensure the app is user-centered and design-first by applying design techniques at every stage of the software project
Engineering & Data Objectives
- Build a plant database with complete technical data sheets
- Enable community interaction and knowledge-sharing
- Integrate weather data and AI-based plant identification
- Provide educational content on soil, climate, and pests
Skills Used
Design Framework
The project followed a double-diamond process — diverging to understand the problem space through research and contextual analysis, converging into defined requirements, diverging again through prototyping and UI design, and converging into implementation. In practice, the design and engineering phases ran too sequentially. The lessons section reflects on what a more integrated workflow would look like.
From problem space to navigable prototype
Research
The research phase began with a contextual and environmental analysis, drawing on IPCC reports and academic literature on urban gardening. Key finding: approximately 78.8% of Latin America's population lives in urban centers — and most cities in the region have little adaptive capacity to climate change. Urban gardening emerged as one of the most scalable local responses, but also one of the least supported by digital tools.
A market scan confirmed the gap: existing apps were either international in focus, technically complex, or not designed for small-scale urban gardeners. This validated both the opportunity and the direction for myPlant.
From the research, three user types were identified: the Jardineiro (the everyday gardener and primary user), the Admin (managing plant and garden model data), and the Community Manager (moderating forums, tutorials, and the marketplace).
Product Design
Product design centered on mapping the full scope of the platform through a use case diagram with 22 use cases across all three roles. From there, 26 functional requirements and 11 non-functional requirements were derived — covering plant database search, a garden design and planning tool, a planting calendar, weather integration, AI-based plant identification via Google Lens, a community forum, a plant exchange marketplace, and GPS-based mapping of local gardens.
The platform was scoped to support three concurrent user roles, five external service integrations, and three parallel databases. It was an ambitious product vision — and one that later created real engineering challenges, particularly around deciding what to learn first.
UI Design
The interface was designed in Figma as a high-fidelity, navigable prototype. The visual language draws on the culture of gardening — deep greens, earthy neutrals, and approachable typography — while following accessibility principles for a general, non-expert audience.
Key screens: landing page with feature highlights, a personalized dashboard with weather data and garden status, a plant species library with individual technical data sheets, a visual garden planner for sketching layouts, an AI identification flow via Google Lens, and a categorized community forum.
The complete navigable prototype was built in Figma.
From design artifacts to working software
Requirement Elicitation
Requirements were elicited through use case analysis and structured documentation. The process produced 26 functional requirements and 11 non-functional requirements, each rated by difficulty and priority, across three actor types.
Three user roles defined
Jardineiro (primary end user), Admin (manages plant data and garden models), Community Manager (moderates forum, tutorials, and marketplace).
Full platform scope mapped
Plant search and technical data sheets, garden design and planting calendar, weather API integration, AI plant identification via Google Lens, community forum, plant exchange marketplace, GPS map of local gardens.
Performance, usability, and integration constraints
Including map load time under 30 s, preference for open-source stack, Google Maps integration, health-ministry-aligned medicinal plant data, and a three-garden limit on the free tier.
Domain Class Diagram
The domain model captures the core entities and their relationships — the conceptual bridge between product design and the database schema. Main entities include Jardineiro, Jardim, Planta, FichaTécnica, ModeloJardim, Comunidade, MarketplaceEventos, and ConteúdoInformativo.
MySQL Relational Database
The relational model was implemented in MySQL using TypeORM, chosen for its dual SQL/NoSQL support and native TypeScript integration. The schema runs across three databases in parallel: MySQL/PostgreSQL for structured relational data (users, gardens, plants), MongoDB for lists and location metadata, and Redis for session cache and notifications.
Test Plan
A structured test plan was developed covering primary use cases, including both the happy path and edge cases — particularly around absent data, invalid inputs, and security concerns such as offensive content submission to the forum.
| # | Use Case | Objective | Expected Result |
|---|---|---|---|
| 1 | UC1 Plant search | Search for a plant that exists in the database | Technical data sheet displayed |
| 2 | UC1 Plant search | Search for a plant not yet in the database | Error message with redirect to community forum |
| 3 | UC2 Garden models | Browse and edit a suggested garden model | User can add preferred species and save layout |
| 4 | UC5 Plant ID — forum | Submit a photo and question to the forum | Post visible to community members for responses |
| 5 | UC5 Plant ID — AI | Upload image to integrated Google Lens tool | Results page with plant information returned |
| 6 | UC5 Security | Attempt to submit offensive image or text | Content blocked by moderation system |
| 7 | UC8 Forum search | Search for keyword with existing threads | Matching threads listed and displayed |
| 8 | UC8 Forum search | Search for keyword with no existing results | Prompt inviting user to start the first thread |
App Development
The application was built with a Node.js + Express backend and a Vue.js + TypeScript frontend, deployed via a serverless hosting platform. The architectural pattern is MVC with a modularized structure — minimal dependencies per component, with TypeORM managing database connections.
By the end of the project, the relational model was implemented with all relationships defined, a complete plant data sheet was created, and the planting date timer feature was built and working. Full search functionality for the end user remained partially incomplete, a direct consequence of scope and timeline constraints discussed in the next section.
What I would do differently
This project ran alongside a post-covid health recovery, a full restart after canceling the first concept, and a steep self-directed learning curve in languages and frameworks. The reflections below are specific to myPlant, but inform how I approach every project since.
The core tension: I designed myPlant as a UX designer first and approached engineering second. That sequencing created a gap between what I had built in Figma and what was realistically achievable — a gap I only began to see clearly once I was deep into implementation.
Design and engineering need to be one workflow, not two sequential phases
My design background gave me a strong product vision, but also meant I designed features without engineering constraints in mind. The drag-and-drop garden planner, the Google Lens integration, the GPS map of local gardens — all made sense as UX flows. What I hadn't considered while designing them were the architectural implications: which features required real-time data, which needed external API calls, which required a NoSQL store versus a relational one, and which were simply out of reach for one developer learning the stack in parallel. In a future project I would prototype in Figma and validate technical feasibility at the same time, making sure every design decision is grounded in what is achievable with the skills and stack available.
Overscoping created decision paralysis more than it created ambition
Twenty-six functional requirements across three user roles, five external service integrations, and three parallel databases was an ambitious specification for a solo project. The consequence wasn't just incomplete implementation — it was that I didn't know where to start learning. Should I focus on Vue.js or Node.js first? TypeORM or raw SQL? Docker or just get something running locally? Scope directly drives the required tech stack, and the tech stack drives learning priorities. A smaller, well-defined MVP — say, plant search and basic garden creation — would have produced a more complete and stable product, and given me a much clearer path through the upskilling required to deliver it.
The engineering training changed how I design — permanently
Despite the challenges, completing a Software Engineering postgraduate has fundamentally changed how I approach design problems. I now think in data models when I draw components. I consider API response shapes when I design loading states. I ask about database constraints before committing to a feature flow. That integrated perspective — not as a developer, but as a designer who understands engineering — is the most durable thing myPlant taught me, and it shows in every project I take on since.