Founder | | 6 min read
Studying and building at the same time, and whether that is sensible
A realistic account of divided attention, deadlines, product scope and the limits of combining university with a company.
Studying engineering while building a company can make sense for a period. It is not automatically sensible, productive or admirable. The answer depends on scope, support and whether either responsibility is being treated as imaginary.
University has fixed commitments. The company has unpredictable ones. An assignment has a deadline known in advance. A failed service or a provider request can arrive without checking the academic calendar.
The challenge is not finding a perfect routine. It is deciding what does not get done when both sides ask for attention.
The work uses different kinds of focus
Engineering study often requires sustained concentration on one defined problem. Company work fragments attention across code, support, suppliers, public copy and compliance.
Moving between them has a cost. Reading regulatory guidance for an hour and then returning to a technical calculation is not the same as two uninterrupted hours on either task. A calendar can allocate the time without removing the mental switch.
I had to stop treating every empty space as available. Travel, preparation and recovery are part of the schedule even if they do not produce a document or commit.
A small scope became an operating control
The product cannot contain every idea when the company has limited attention. That is true for any early team, and it is more obvious when the founder is also studying.
Read-only account information is a clear boundary. No payments means no payment journey to operate. No client funds means no stored balance system. Keeping the assistant optional means the core transaction and budget views have to work independently.
These decisions are not excuses for poor quality. They reduce the number of systems that require quality at the same time. A narrower product can still be difficult, but its responsibilities are easier to name.
Deadlines are not all equal
Some work can move. A visual refinement can wait. A regulatory request, security issue or user data concern may not. An exam date usually cannot.
I separate tasks by consequence rather than by which one feels most interesting. Work affecting data access, customer communication or a live failure takes a different priority from an idea for a new screen.
This does not create a calm week. It creates a reason for the order. When two immovable commitments collide, the honest answer may be that help is needed or a release cannot happen.
The company cannot depend on constant overwork
A plan based on unusually long days is not a stable operating model. It hides the real cost of each feature and leaves no capacity for errors.
I have had periods where the combination was too much. The result was not heroic output. It was slower thinking, avoidable mistakes and work that needed another pass. That experience made limits less theoretical.
The practical response has been to reduce simultaneous projects, document decisions so context is easier to recover and avoid promising dates merely because a task looks small. Regulated review and provider dependencies can add time that a personal calendar does not control.
University is not only an obstacle
Studying provides structure and exposure to people solving different problems. Engineering reinforces habits that matter in software: state assumptions, test the system, measure the result and document where a model breaks.
It also prevents the company from becoming my only environment. That distance can expose product language that makes sense inside a repository but not to a person seeing the service for the first time.
The benefit is not a special founder advantage. It is another source of learning, with its own workload and obligations.
There are limits to doing both
The company still needs continuity when I am unavailable. Credentials cannot exist only in my memory. Incident contacts need a backup. The principal firm needs accurate information about who is responsible for the regulated service.
As the product reaches real users, those requirements become more important. A student timetable does not reduce the sensitivity of connected account data. Growth in responsibility may eventually require a different balance between study and company work.
So, is it sensible?
It is sensible only while the scope remains honest and the obligations on both sides are met. It is not sensible if the company depends on skipped study, hidden exhaustion or controls that exist only when the founder has spare time.
For me, the combination has worked well enough to reach this stage. It has also shaped the product into something narrower and made the need for oversight obvious. I would not present it as a universal route or a test of commitment.
Building while studying is a constraint, not a personality. The useful question is whether the work can still be done carefully. When the answer becomes no, the plan has to change before the public claim does.
That standard applies on ordinary days too.
For current service details, read the company's open banking explanation and Privacy Policy.