Introduction
At 10:30 on a Tuesday night, an app idea can feel both promising and exhausting.
You have opened the laptop after dinner. Tomorrow is a workday. The idea has returned often enough to feel serious, but your calendar has made very little room for it.
Perhaps you have already saved references, spoken to a developer and created a document called “Final Features”. There may be three versions of that document. Meanwhile, the question that matters most remains unanswered: how will you run this thing once somebody starts using it?
Building a side hustle with a full-time job means designing around limited availability. Your first product needs to make a useful promise that you can keep during an ordinary, occasionally difficult week.
That constraint can help you decide what to build.
Start with the week you actually have
It is easy to plan around an imaginary Saturday when nobody calls, you wake up early and every decision goes smoothly.
Look at the last month instead. How much uninterrupted time did you reliably have? What happened during a busy week at work? Which evenings were already spoken for?
Suppose you can give the business six hours a week. As an illustrative starting point, you might reserve two hours for customers, two for improving the product, and two for administration and unexpected problems. Your own split will differ. The point is to leave room for operating the service after it launches.
If development discussions use all six hours, customer messages will arrive in time you have never budgeted.
Write down your available hours, your response window and the amount you can commit to the experiment. Those are product requirements. They deserve a place beside the feature list.
Choose a promise that fits those hours
Imagine you want to help final-year students prepare for job interviews. This is a hypothetical example, but the trade-offs are familiar.
The big idea could become a marketplace with mentors, video calls, subscriptions, AI feedback and employer partnerships. A manageable first offer might be much narrower: one weekend mock interview for students preparing for a particular kind of entry-level role.
That gives you decisions you can actually make. Which students can you reach? How many sessions can you deliver? When do bookings close? What happens when someone needs to reschedule?
A clear promise also tells you what the customer needs from the product. They need to understand the session, choose an available slot, receive confirmation and know how to attend. A mentor leaderboard can wait until there is a reason for it.
Before adding a feature, describe the customer problem it solves in that first offer. If the explanation depends on a much larger future business, put it on a later list.
Design the customer's Tuesday, too
Your availability and the customer's expectations have to meet somewhere.
Someone may book on Tuesday morning while you are in a meeting. They should still be able to tell whether their booking succeeded. They should know when they will hear from you and where to find the session details.
Work through one customer journey from beginning to end:
- They find the offer and understand who it is for.
- They choose an available session and provide the necessary details.
- They complete the required booking or payment step.
- They receive a clear confirmation and joining instructions.
- They can request a change through a route you actually monitor.
Some steps might use existing tools. You might handle others manually at a stated time. The important thing is that the customer can complete the journey without guessing what has happened.
For a paid first version, confirming a transaction and recording a booking accurately are part of delivering the service. Reducing scope should make that basic promise easier to keep.
Count the work each new customer creates
A feature can look small on a screen and create a surprising amount of work behind it.
Offering “any mentor, any time” creates scheduling, availability and reassignment questions. Letting people buy several types of sessions creates different instructions, pricing and support needs. Opening a community creates something that someone must moderate and maintain.
For every proposed feature, ask:
- What will I need to do when a customer uses it?
- What happens when the normal process fails?
- Can that wait until my next working window?
- Who handles it if I am unavailable?
Keep track of manual work during the pilot. If arranging every session takes half an hour of messages, write that down. After a few actual bookings, you will have a much more useful automation requirement than “we need a dashboard”.
You may discover that a reliable booking flow would give you back more time than the impressive feature you originally wanted.
Give the experiment a boundary
The phrase “I’m working on an idea” can quietly stretch across a year.
Set a small operating boundary: a limited number of customers, a defined offer and a date when you will review what happened. A four-week pilot, for example, is a period for learning about the offer and workload. It is not a promise that a custom application can be designed and delivered in four weeks.
At the review, look at evidence you can describe plainly. Did people understand what they were buying? Did you deliver it as promised? Did the same problem keep appearing? Could you handle the work alongside your existing commitments?
Money matters, but an initial payment alone does not tell you whether the business is repeatable. You also need to understand the time and direct costs involved in serving that customer.
Continuing, narrowing the offer and pausing are all decisions you can make from that evidence. Expanding the feature list should have a reason of its own.
Pay for development when the work becomes clear
Custom development starts to become easier to justify when you can point to a specific job it needs to do.
Perhaps customers need a booking experience that your current arrangement cannot support. Perhaps repeated administration is consuming the hours you intended to spend delivering the service. Perhaps the product itself is the experience being tested, so a manual arrangement cannot answer the question.
Write a short brief before requesting an estimate:
This helps [a specific person] achieve [a specific result]. Today we deliver it through [the current process]. The first version must handle [one complete journey]. We can keep [named steps] manual. Our main constraints are [time, budget and availability].
That gives a product team something concrete to question, design and estimate. It also helps you recognise proposals that have grown beyond what you can operate.
Craftnotion’s approach to MVP development starts by considering what the next step needs to establish. Depending on the idea, that can involve a prototype, a pilot or a focused first release.
Bring the idea and the constraints
You do not need to arrive with every screen drawn. Knowing that you have six hours a week, a particular customer in mind and one difficult booking process is useful context.
At Craftnotion, we can help turn that context into a product scope, decide what should remain manual and work out what needs design and development.
If you keep reopening the same idea after work, tell us what you want to build. Share who it is for, how you expect to run it and what is keeping you stuck. We can have a practical conversation about a first version that fits your life.
