How to Scope Your Project (and Why It Matters) – The Historical Bible App
This image serves literally no purpose
Whenever you're making any sort of app, you need to scope it; otherwise, it'll become spaghetti of chaos halfway through development. In this post, we'll talk about how to properly scope an app development project and why you should do it in the first place, and we'll use the Historical Bible App I'm building as an example for everything. Don't worry if you're not into biblical history , these principles apply to all kinds of app development projects.
A Quick Introduction (Yes, Let Me Justify My Soapbox)
First, let me introduce myself, if you don't already know. My name is Tomas Heligr-Pyke. I run a full-service digital agency that specialises in app development, and I've worked on projects for government organisations (e.g., Queensland Health), large private companies (Mercedes-Benz, Car Mods Australia), and large not-for-profits (Mater Hospital), plus a myriad of small- to medium-sized businesses.
I develop apps and consult on marketing and the digital landscape. You could say it's my bread and butter.
Why am I writing this? Purely for fun and because I felt like God had been nudging me to help educate the people around me so that they could become amazing developers, too.
If you're not into God, please stick around anyway , this will be highly educational and helpful for anyone.
Luke 14:28–30 (AKA Jesus Was Down With Scoping)
"Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him, saying, 'This fellow began to build and was not able to finish.'" – Luke 14:28–30
Even Jesus told us to scope before we build , otherwise, you're laying the foundations for future frustration.
Sometimes the cost is too great to go solo, you need extra hands, or the technology you can access isn't enough. Thankfully, in our modern age, frameworks and tools make things a lot easier, so the possibilities are endless. But if you ignore scoping, you'll still end up in the digital mud.
Project Management Approaches , Which Flavor Tastes Best?
There are a bunch of ways to manage a project, but here are a few that regularly pop up in the development world:
Waterfall
Classic, linear, and old-school. You do everything in phases: requirements, design, implementation, verification, maintenance , bing, bang, boom. Best for: Fixed requirements, minimal change.
Agile or Scrum
Iterative and feedback-driven. Work in short sprints (1–4 weeks) and adapt. Best for: Projects likely to change, with feedback loops.
Kanban
Visual boards (e.g., Trello, Jira) to track workflow stages. Best for: Continuous delivery and flexible task tracking.
Hybrid or Franken-method
A mix of the above, tailored to your real-world constraints. Best for: Teams with evolving needs, deadlines, and quirks.
Which One for Personal Projects?
Your best bet for personal side hustles: Agile-ish + Kanban.
Use short sprints
Keep a small backlog
Set weekly micro-goals
Iterate regularly
The Historical Bible App Scope – A Quick Dive
This app is designed to track biblical people, locations, events, eras, passages, and even kingdom borders.
Database Planning 101
Below is a simplified schema for understanding complex relational data:
People
id,name,title,alias,gender,date_of_birth,date_of_death,birth_location_id,death_location_id,father_id,mother_id,era_id,certainty,notesRelationships: self-referencing parents/children, locations, era, many-to-many with events and references
Events
id,name,type,location_id,start_date,end_date,era_id,certainty,descriptionRelationships: belongs to location/era, many-to-many with people, references
Locations
id,name,type,latitude,longitude,altitude,certainty,descriptionRelationships: many-to-many with events, one-to-many for people, references
Eras or Periods
id,name,start_date,end_date,certainty,descriptionRelationships: hasMany people/events/borders
Biblical Passages
id,book,chapter,verse_start,verse_end,text,translation,notesRelationships: references events, people, or locations
Borders
id,name,geometry,start_date,end_date,era_id,certainty,descriptionRelationships: belongsTo era
References (Polymorphic)
id,title,author,reference_type,publication_date,url,descriptionPivot:
reference_id,referenceable_id,referenceable_type
App Pages & API
For each model:
Index or List
Detail View
Create or Edit
Tech Stack
Backend: Laravel 12
Frontend: Inertia.js, React 19, TypeScript, Tailwind, shadcn/ui
API Docs: Scribe
Why Scope Matters (No, Really, It Does)
✅ You Won't Get Overwhelmed
Having a plan means fewer mid-project panic attacks.
✅ You Know the Tech Stack
Pick your stack early. Laravel 12 + React 19 = 💪
✅ Future-Proofing
Handle later features without refactoring your whole app.
✅ Easier Collaboration
Scoped projects make onboarding new devs (or future-you) easier.
Example Roadmap (Scrum-ish Style)
Define Your Backlog
People CRUD
Events CRUD
Genealogical merges
Timeline views
Prioritise Your Sprints
Sprint 1: Laravel setup + migrations
Sprint 2: People model relationships + UI
Sprint 3: Event timelines, references
Sprint 4: Map and border features
Daily or Weekly Check-Ins
Set a weekly goal: "By Friday, People Index/Create/Detail should work."
Review & Retros
Reflect, adjust, and improve sprint by sprint.
Final Thoughts: Plan Before You Build
You could take a million directions in an app. But without a roadmap, you'll likely veer off or rewrite big chunks.
Take a moment to:
Plan your data structure
Pick your stack
Choose your methodology
You're already way ahead if you start with a plan.
Credits & Handy Links
If you're not into God, swap the references for other historical/genealogical data , the same logic applies. But hey, we're building a Historical Bible App, so do what you will with that!
Thanks for reading, and I'll see you next time when we (hopefully) start building some real features. Or maybe I'll rant about forgetting to name my Laravel migrations. Either way , happy coding!