"So you're a software developer? You know I've got this app idea..."

Sounds familiar?

I think software developers can all relate to this situation. Everybody has random app ideas, especially your family and friends when they realize that you've got what it takes.
On the other hand, we developers are not devoid of ideas either - it's just we know the market (which is saturated) and the process (which is whacking).

And I'm not talking about coding. Hell, that's actually the fun part! - after all the work you have to put into consolidating business logic, creating UI/UX design, user workflows, database schema, etc.

Luckily we can usually control our friends' desires - but let me paint you a different picture.

Here's the same thing but with a twist:

"I've got this app idea... And I'll pay you to do it."

OK. You might be asking - that’s just the tip of the iceberg, what are the variables? Money, complexity, platforms, who are you going to work with?
Bear with me, because I’m going to show you how I tackled this challenge! I hope my example will help to explain a few things.

Here's the story.

Idea meets me

Truth be told I count myself extremely lucky.
It was a small design studio who first found me with this kind of request and there were extenuating circumstances:

1. The application started as a proof-of-concept thing.

They planned to iterate on it, trying out ideas during development, so nothing was set in stone.

2. I had a lot of freedom.

Which is a blessing and a curse as well. A blessing because I had a chance to try out new stuff, experiment, and learn. I'll elaborate on the curse later...

3. The app was not going to go full-public.

It was planned to be used only between co-working companies. No huge responsibilities, or significant business security concerns.

Just some details. This was a full-stack web app (PERN stack), with user authentication, separate admin/user interfaces and artifact management - consequently involving a database and storage service.

All the above meant that I had space to learn, improve, and make mistakes, while being paid for it.
Here’s the real kicker though: for me, it would have worth it even without the money - just for the experience.

Idea meets technology

The first bumps along the road came when I realized that my client's app idea was as undeveloped as any random idea, people usually come up with. They could describe the apps main purpose, plus they had some design sketches, but that's about it. A good old idea.

• No admin/user interface or workflow design - basically no ideas on how admins should be able to configure user privileges and manage data. Literally nothing to help me figure out the database schema and the supported operations.
• The wanted to manage ambiguous artifact types.
• Also, they had super flexible role-based access management expectations.

This is where freedom can become a burden because you end up to be the expert who is expected to bring the best of all worlds:

1. Find viable, sustainable, and scalable technical solutions...

2. ...but also don't steer to far from customer expectations...

3. ...while writing super flexible code to be able to redesign on a whim.

The solution for me was twofold: asking the right questions, and managing the product responsibly. Let me explain.

Ask the right questions

You can easily end up in a situation where your app specification is something like this:

"I want to be able to log in and like... upload and download stuff. Then users could register and can download stuff. But certain people could only download certain stuff!"

Normally you wouldn't get a "specification" like this at a web development studio. You would get interface design sheets, database schema specs, maybe even a complete design theme.
You're not that lucky this time. Now what.

Well, you cannot teach product development to your client, especially if you're also inexperienced - but you can ask questions until a working solution unfolds! Basically: Review, build, synchronize.

In steps:

1. Review your client's feature requirements.
2. Construct technical solutions.
3. Align technical implementation details and constraints with client expectations. Educate your client.
4. Adjust your implementation to be in accord with your client's needs.
5. Rinse and repeat.

Be thorough, I can’t stress this enough. It can be super annoying to redesign a whole database or API, just because you were not extensive enough in explaining limitations created by a certain implementation choice, at a certain point.

Be your own product manager

At large software companies, you always have a team lead, or some kind of manager, who serves as the first layer of defense.

Basically how it works:
Other parts of your company may throw implementation ideas and random tasks at you, and your manager is the one who decides what tasks are accepted, depending on your team's experience, scope, time restrictions, etc.

As a freelancer, you'll have to step up and steer your client away from design ideas that would result in harmful technical decisions.
Communicating technical debt is not trivial, and there are whole articles about it.

The point is, we can do anything with code, but it doesn't mean that we should. As the developer, you should be the one who draws the line.

Careful source code management is also key. You won't be able to adapt fluently if your git repo is a mess. It's pretty hard to revert features if your commits are not granular enough and you don't document well with proper commit messages and tags.

Everything has a price

If you're alone, or you have little help (like a couple of designers throwing concepts and UI mockups at you - which is not always help, let's be honest) you probably have to consider what you're capable to do alone given a specific amount of time and resources. When your client wants something beyond your limits, the best is to expose these limitations and the price they might have to pay (in time, or resources) to accomplish what they want, despite the boundaries.

I hope you've enjoyed this read! Happy coding!