EasyTrip was a software engineering course project built by a five-person team. Its goal was to help people plan travel itineraries around destinations, timing, reservations, and related constraints. The archived application and setup instructions are available in the EasyTrip source folder, which is also linked from my project index.
This retrospective distinguishes between that broad product goal and what the repository directly demonstrates. The README describes planning and exporting itineraries, including ordering locations based on practical factors. The checked-in prototype more concretely shows account flows, user profiles, and itinerary creation, editing, and deletion. I would not infer a complete optimization engine or polished export workflow from the archived code alone.
What the source shows
EasyTrip is a Python web application using Flask, Flask-Login, and SQLAlchemy. Server-rendered templates cover the home page, sign-up, login, profile, itinerary, and itinerary-editing views. A SQLite database stores three central models:
User, with a unique email, password field, name, and related itinerariesItinerary, owned by a user and associated with a modification timestampLocation, attached to an itinerary with an order, address fields, and departure time
At a high level, the implemented path looks like this:
browser -> Flask routes -> SQLAlchemy models -> SQLite
|
\-> server-rendered templates
That is a compact architecture for a course prototype. It keeps the UI, authentication flow, and persistence model close enough for a small team to understand without introducing extra services.
Collaboration lessons
The most durable lesson is to make the shared domain model explicit. “User owns itineraries; itinerary contains ordered locations” is simple language, but it gives a team a common reference for routes, templates, database relationships, and acceptance tests. Agreeing on those nouns and ownership rules early can reduce ambiguity when work is split among contributors.
Small, demonstrable slices are also preferable to broad feature labels. “A signed-in user can add a location to an itinerary” is easier to review than “finish trip planning.” For a student team, a lightweight pull-request description with context, screenshots for UI changes, and test notes would be a useful process goal. The repository does not establish that this exact review process was used, so it is better treated as a lesson for future collaboration than as project history.
The same caution applies to API claims. The archived code is a server-rendered Flask application, not evidence of a Node service or a formal REST resource layer. If the application needed multiple clients later, an API could be extracted around users, itineraries, and locations. That would be a future design decision, not a description of the submitted project.
What I would change
The source is valuable precisely because it exposes unfinished edges. A rebuild should start with tests for authentication boundaries and itinerary ownership, then cover create, edit, and delete behavior. Password handling, validation, error states, and database migrations deserve explicit review before any real deployment. Location ordering should have a documented rule, especially if departure times and attraction constraints affect it.
I would also revise the README so planned behavior and working behavior are separately listed. That small documentation habit makes a prototype easier to evaluate honestly and gives the next contributor a realistic starting point.
EasyTrip remains a useful team artifact, but its strongest value is not a claim that every travel-planning idea was completed. It is a concrete example of translating a shared concept into routes, templates, and related data models. The Data Science Toolbox retrospective looks at a different course project organized around containers, while Grief to Action discusses the additional caution required when only high-level design notes are public.