How to realize your client's random app idea
Tags: productivity, webdev, career, motivation
Published: 2020-07-07 19:18:36

---
title: How to realize your client's random app idea
published: true
description: Article about on-demand app development.
tags: #productivity #webdev #career #motivation 
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/4cf21l3pbon5tnscq5ct.jpg
---

# "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
![app idea meme](https://media.giphy.com/media/KENUDmJeWHbusfvmkP/giphy.gif)

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](https://www.geeksforgeeks.org/what-is-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
![robot gif from series](https://media.giphy.com/media/Pu5F5t64WNKYE/giphy.gif)

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
![question gif from series](https://media.giphy.com/media/8RuJ23GPbruW4/giphy.gif)

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
![council of characters](https://dev-to-uploads.s3.amazonaws.com/i/nk3609fbemhe3uix4g0z.gif)

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](https://devops.com/communicating-with-management-about-technical-debt/) 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!
![farewell gif](https://media.giphy.com/media/LQjqYNrXB0fDy/giphy.gif)