Atlantis

Capstone project for my degree in Systems Analysis and Development at UFPR (defended March 2023). The product is live on Vercel; the Supabase database is currently paused, so the demo runs in read-degraded mode.

The problem

Setting up a healthy home aquarium is harder than it looks. As the ecosystem grows, the constraints get sharper — water parameters (pH, temperature, dGH, salinity), filter capacity, substrate, plus species that turn territorial under the wrong conditions. Get it wrong and fish die or attack each other.

A hobbyist's only options today are:

1. Forums and blogs — abundant but contradictory. Three sites give three different temperature ranges for the same species.
2. Pet shops — incentives are misaligned. Selling the next bottle matters more than telling you the rare cichlid you want will eat your tetras.
3. Existing tools — usable but limited. I surveyed three:
   • AqAdvisor: solid compatibility math, hostile UI buried under ads, no source attribution.
   • Aqua-Fish: nice species pages, but no aquarium-level compatibility check.
   • The Aquarium Wiki: collaborative, but anyone edits and you can't tell who.

Comparing the same species (Betta splendens) across the three returned different minimum volumes, temperatures, pH, and dGH ranges. The underlying problem isn't UI — it's that nobody's accountable for the data.

The approach

Atlantis treats data quality as the core product, not a side concern. Three design choices flow from that:

1. Two-tier user model: hobbyists ("aquarists") consume the data; credentialed specialists curate it. Every species record is signed with the specialist who last edited it, surfaced as a link to their public profile (bio, e-mail, professional link).
2. Compatibility as live feedback, not a final report. As the user adds fish, the aquarium card recomputes parameter ranges, minimum volume, filter throughput, thermostat wattage. Conflicts highlight in red on both the aquarium and the offending species cards — you see why a combination breaks, not just that it does.
3. Persisted plans, not one-shot queries. Aquarists save aquariums to their account and edit them over time. The plan is a living document, not a calculator session.

Architecture

Three roles backed by row-level permissions: aquarist plans aquariums and reads the database; specialist also writes species, substrates, and foods; admin also manages user roles. Permission checks live in the API routes; the schema is normalised around the fish ↔ aquarium many-to-many through an aquarium_fish table that carries the quantity per species.

Tech decisions & trade-offs

Why pivot from MongoDB to Supabase mid-project? The original plan was MongoDB. When my project partner left and I took over solo, I re-evaluated: the domain is inherently relational (fish ↔ substrate ↔ food ↔ aquarium ↔ user), the queries are parameter-range filters that SQL does cleanly, and Supabase bundles auth + Postgres + storage so I'd ship faster alone. Picking the simpler stack saved weeks I didn't have.

Why Next.js for both front-end and API? Single deployment target (Vercel), shared types between client and route handlers, no second runtime to maintain. For a solo capstone the productivity multiplier was the point.

Why surface the specialist who last edited each species? The whole product thesis is that data quality matters. If the data isn't trustworthy, you've just rebuilt The Aquarium Wiki with prettier CSS. Attribution is the cheapest accountability signal, and it gives specialists a portfolio incentive to keep records accurate.

What it does

The aquarium-planning flow is the demo-able part:

• Live parameter aggregation — temperature, pH, salinity, and dGH ranges narrow as species are added, computed as the intersection of each species' tolerance.
• Volume and equipment sizing — minimum tank volume, filter flow (l/h), and thermostat wattage update as fish join the plan.
• Compatibility flags — temperament alerts (territorial, aggressive toward larger/smaller species) render inline on the species card so the user sees the warning before adding the fish.
• Saved plans — Meus Aquários lists the aquarist's plans; re-opening one rehydrates the editor with all selected species.

What I'd do differently

• Validate the data-curation flywheel first. I built the full three-role app before ever testing whether specialists would actually fill in 19 fields per species. The right move was a Google Sheets intake first, then build the app once the data was real.
• Don't ship a public CRUD on substrates and foods. The catalog is small and slow-moving — it didn't need a full admin UI. A seed file would have done the job and saved several screens of work.
• Plan the database pause. The Supabase free tier pauses inactive projects. The live demo would survive a pause better with a static fallback dataset; right now a paused DB means the species catalog reads empty until I unpause.

Status & links

• Live demo: atlantis-aquarium.vercel.app — front-end runs; database may be paused.
• GitHub: MarcosNespolo/atlantis
• Thesis (PT): full TCC document with requirements, UML diagrams, use-case specifications, and ergonomic-criteria evaluation — available on request.