“Real learning begins when theory meets responsibility.”
Budgitin did not start as a startup idea or a polished product vision.
It began as a Second Year Software Development Group Project at the Informatics Institute of Technology (IIT), a university assignment with deadlines, marking schemes, and expectations.
But it quickly became something more.
What we were building stopped feeling like just coursework.
It began to feel like a real system solving a real problem, and that shift changed how we worked, thought, and collaborated.
From Assignment to Ownership
Initially, Budgitin was simply a project brief.
A problem to analyse.
A system to design.
A solution to submit.
But as we explored financial challenges, user needs, and system requirements, we realised that this was not a fictional scenario. The problems were real, and so were the people affected by them.
That realisation introduced something new: ownership.
We were no longer working just to meet requirements.
We were working because the solution mattered.
Learning to Work as a Team
One of the biggest lessons from building Budgitin was understanding that software is never built alone.
Each team member brought different strengths, perspectives, and responsibilities:
- Technical decision making
- Financial understanding
- Machine learning logic
- Web and mobile development
- Communication and presentation
We learned quickly that progress depended on clear communication, trust, and accountability.
When one part of the system was delayed, it affected all other parts of the system.
This experience taught us how important it is to:
- Respect timelines
- Communicate early
- Support each other during challenges
- Make decisions as a group, not individuals
These were lessons no lecture could thoroughly teach.
Bridging Theory and Practice
University courses teach concepts such as architecture, design patterns, requirements analysis, and system modelling. Budgitin taught us how those ideas behave in the real world.
We learned that:
- Requirements change
- Initial designs evolve
- Not every idea works as expected
- Simplicity often beats perfection
Applying theory to a living project forced us to think critically, adapt quickly, and make informed trade offs rather than ideal ones.
Managing Time, Pressure, and Expectations
Unlike small lab exercises, Budgitin had long term pressure.
We had to balance:
- Multiple modules
- Personal responsibilities
- Deadlines and reviews
- Group coordination
This taught us how to plan realistically, prioritise tasks, and manage workload under pressure. We learned that good software is not just about writing code, it’s about discipline, consistency, and responsibility.
Building Something That Feels Real
One of the most rewarding moments was realising that Budgitin didn’t feel like a prototype.
It felt usable.
It felt purposeful.
It felt like something people could genuinely benefit from.
That feeling changed how we tested, documented, and refined the system. Quality mattered more because users were no longer imaginary.
Mistakes That Made Us Better
We made mistakes, and that was essential.
Some features took longer than expected.
Some decisions had to be revisited.
Some assumptions didn’t hold up.
But every mistake improved our understanding. We learned how to reflect, adjust, and move forward without losing momentum.
That mindset, learning through iteration, became one of our strongest takeaways.
Beyond Marks and Grades
Budgitin taught us that success in software engineering is not defined solely by marks.
It’s defined by:
- How well a team collaborates
- How clearly a problem is understood
- How responsibly is a solution built
- How much impact can the system have
This project showed us what it means to think like engineers, not just students.
Why This Experience Matters
Because it prepared us for real world development.
Because it turned theory into practice.
Because it taught us the importance of accountability, teamwork, and adaptability.
Budgitin will always be more than a university project to us.
It represents the moment we stopped learning about software engineering —
and started becoming software engineers.
