Developers · Software

What's the first step in developing a software product, if you're not a developer?

Kristy Dalton CEO of Government Social Media LLC

August 12th, 2014

I'm the CEO of a start-up that earns revenue via government consulting and web-based training. I have an idea for a cloud software product that will solve a challenge for state and local government agencies (my background is in city government, and I would have loved this product). I'm the expert in how the software should function, and I have ideas for the user interface - but I'm not a developer. What should I do first? My initial thought is that I need to learn about processes for software architecture and prototyping (from a leadership approach). But I'm also concerned about wasting time learning aspects I don't need to.

Graeham Ford-Feliz CEO at Emergent Coast

August 12th, 2014

It starts with customer development.  There are many techniques and tools.  

I usually look to my personal network to start, but also like to use to do some landing page testing of strangers.

Like mentioned above, there are tons of things to do before a line of code is written.  I've even heard of people funding developer costs from pre-sale revenue made off of a simple slide deck.

Best of luck :)


August 12th, 2014

From my experience I have to agree with Kevin Wright and therefore I would recommend that you find a technical partner (if you can afford one) or a technical co-founder. I disagree that you should jump into app designs and coding before you solve this problem. For example if you started coding right away you may be stuck with a platform that isn't very well suited for the long term. Here are a couple of things I have learned from working with start-ups:
1. Don't look for just a developer/engineer but look for a person that is comfortable with the role of a product manager or CTO if you are going to essentially build a technology company.
2. Technical strategy is crucial and mistakes are very costly so before you make any decisions on platforms, ecosystems or programming languages make sure to consult with a person that will understand the technical and financial impacts of your decision.
3. Understand from day one that you need a team and not a single technical individual. For example in your case you may need a designer, a mobile developer and back end database developer among other roles. The benefit of having a technical co-founder is that they can create the team you need to get things done correctly. Avoid the "jack of all trades" developers if your business is based on technology. You will need real experts in several areas.
4. Understand the difference between a project and a product. You will need help with product life-cycle management in order to be able to scale as your business grows. In other words be prepared for constant change as you move forward.
5. See all other comments above :-)
Good luck and keep moving forward!

Joe Monastiero CEO, Founder nFlate

August 12th, 2014


I recently went through the same process, so I'll tell you how it resolved itself. I'm fairly technical, but I do not write code, not since my college days. I had an idea for a SaaS company and after bouncing the idea off of several close associates whose opinions I trusted. I decided to move forward with concept.

I quickly and accidentally reconnected with an old CTO colleague of mine that was looking for something at the same time. We agreed to attempt to raise some capital together to float the idea, basically a paper napkin concept. We both had very successful careers and several solid exits, albeit as minority-share founders. Two things happened - we found out that no one (at least in the seed-level VC world) was funding companies without a product and small traction. Everyone loved the idea AND the team, but no one would write a check without at least some POC. In the time we wasted dancing with VCs, we also did not build anything, basically thinking out loud "We'll get funded. We're too good not to.". Wrong.

My friend and I parted ways amicably and I immediately went to a local startup weekend looking for some quality engineers to help with the project. In an extraordinary turn of events, I found 3 solid engineers and during that weekend, basically built the prototype. That was 7 months ago. I've been bootstrapping the project, getting maybe 4-8 hours per week out of each of the engineers, that are 100% committed to the project and ready to leave their day jobs once we get funding. I've added a few high quality advisors to the team and in my estimation, we're about 8 weeks from beta and will raise our 1st Angel round within a similar timeframe.

I did immerse myself in the subject matter completely, but in parallel. I'd suggest you get a clear working knowledge of how AWS, for example, works and all of its nooks and crannies. It will provide a great operational overview of the cloud world. You need to be the architectural expert (not a coding architect, but certainly the visionary architect).

Scour the local community, using Meetups and Startup weekends. I'd suggest avoiding incubators and accelerators until you have a team and start the code writing journey.

Good luck.


Benjamin Curtis Co-Founder at Honeybadger Industries

August 12th, 2014

A great first step would be to prototype the screens of the application.  They don't have to be fancy -- you can use or -- the goal is to just get the ideas out of your head and into a form that other people can consume.  Then you can take that to potential customers (to see if you're headed in the right direction) and potential development partners (so they can determine if the project is interesting and/or how much effort it would take to build your vision).

Good luck!

Kevin Wright Lead Scala Developer at Anomaly 42

August 12th, 2014

Find a co-founder!

Processes, best practices, techniques, frameworks, tools, libraries, communities... For any non-trivial app, the amount you'd have to learn is overwhelming.

Just think about what a developer could offer that would take you years to acquire:

- A good idea of what's possible, and the relative difficulty of implementing alternative ideas
- The ability to estimate timescales
- Established contacts with the dev community if you need to grow
- Years of past experience in the sort of problems that you *will* encounter
- A good knowledge of off-the-shelf parts that could help build your app

Think how you'd answer if a developer appeared here and asked for a quick cheat-sheet to get them up to speed in government consulting and web based training in a scant few weeks, with no prior experience.

robert carter

August 12th, 2014

Agree with Ben.  You don't need to know how to build it, just what to build. Start getting those ideas down and then find some folks you trust to build it or help find folks who can.

Michael Calleia Helping companies build better products and teams. UX and Product Management.

August 12th, 2014

  • There is a ton that can be done pre-development, off the top of my head:
  • User research. Talk to potential users. Ask to watch them do the thing you want to bring change to.
  • Draw user journeys of how people get things done now
  • Draw a user joinery of how they will get things done using your product
  • Business Model Canvas.
  • Market sizing, which will help better identify your market and users
  • Build personas based on your research
  • Write user stories to help guide what functionality is needed for your MVP and prioritize
  • Sketch and wireframe the UI.
  • Sketch user flows to show the workflow within your product

You will be able to use these to paper prototype your product for testing as well as to show engineers when it is time.

Rob G

August 13th, 2014

Think of remodeling your bathroom.  You can hire a general contractor whom you trust because you have interviewed him/her and checked references.  This person could do some or all of the work, but most often they will sub out some of the work to experts (plumber, electrician, etc. - UI person, UX designer, ecommerce expert).  Perhaps you hired a designer up front and he/she will work with the general contractor to see that your/their 'vision' is fulfilled (i.e. UI/UX).  You didn't need to be a plumber or electrician or tile setter, but you did need to know what you wanted in enough detail that you could communicate with the designer and the general contractor.  If you did things properly you also got a permit from the city and had the work inspected (i.e. a technical review) to be sure the GC and the trades people are doing things according to best practices and to protect you and future homeowners - i.e. code reviews.  If you've done a remodel or two maybe you don't need to hire a designer and a GC. Maybe you have managed the remodel on your own.  Maybe you just don't have the budget, you have no bathroom currently and you are planning a major remodel next year so you do a MVB ("minimum viable bathroom).  Maybe you know enough to set some tile or plumb a toilet, but you are still not a tile setter or plumber and you don't need to be.  When you hired that tiler setter with the lowest bid and he told you that you didn't need to reinforce the subfloor and now a year later your tile is cracking, now you know a little bit about 'best practices' for setting tile and you know that you need to ask more questions and do more research on tile setting "best practices".  Your plumbing isn't leaking, but do you know if it was done right?  If you add another bathroom on the 3rd floor will the old plumbing "scale"?  Will the electrical service and panel scale? (i.e database and APIs).   Those are things that an experienced GC will look out for.  He/she doesn't know what your future 3rd floor addition will look like, but s/he knows enough to ask the right questions and plan for the future.  That is also why the city required you to get a plumbing inspection - i.e. an expert to review your plans as well as the progress.  When the plumber knows his/her work will be inspected he knows he has to do things according to code (i.e. best practices).  The inspector (i.e. your technical advisor) can tell you whether the plumber is doing a good job or not and this also gives you some feedback on your GC.  Now the next remodel project will be easier because you have some experience in planning, communicating with trades people, etc.  Now think about what you would need to do/know to design/remodel a bathroom for someone else.  Now you not only have to solidify YOUR ideas enough to communicate with the trades people, but you need to be sure you are understanding your customer's needs/wants/ideas, current trends, and a little bit about building codes - enough to tell you client whether they need one or not and enough to know if the GC is doing things properly.  So this time around you will start by interviewing your customer to understand their needs (you need interview skills to find the prospects and ask the right questions). You are the subject-matter expert so you know the questions to ask that perhaps your customers wouldn't even think of.  You will need to know things like how many people in the family, what are their routines, do they entertain a lot, do they have kids (boys or girls), ages, what alternative do they have (other bathrooms - i.e. competition), etc. You will need to know how this bathroom interfaces with the rest of the house (i.e. sewer, electrical, etc.)   To confirm that you and your customer are really on the same page you will have to create some sketches (size and shape of the room, entrance and egress, location of fixtures, etc.) 'use zones', etc., so you will need some basic sketching skills (for building software these will be wireframes and screen UI/UX mockups, use cases and maybe user stories, etc.).  Once your customer reviews your sketches and use cases they will likely suggest some changes and you will go back and forth until you agree on the basics - i.e. iteration. Once you and your customer agree on "functionality" (i.e. how it works and where things go and how users will use it) then you need to know what the finishes will be (colors, textures, stainless VS brass, marble VS vinyl, where the tile borders will be located, etc.) and also agree on specific fixtures (this toilet VS that, this shape of faucet VS that, etc.  This is the UI/UX (how many screens, how to get to them, menus, buttons, colors, animation, etc.).  Then (maybe) you will prepare multiple sets of formal drawings that show all the details.  Depending on the complexity of the project this could be some informal line drawings on a few pages of notebook paper or it could be a whole set of architectural drawings that include a 'site plan" (i.e. an overall site map that shows the major components and how they interface) plus foundation drawing the the foundation contractor, framing for the framing contractor, electrical, plumbing, etc. These are not only used by each trade (i.e. developer, UI/UX designer, Db expert, etc.), but the inspector needs this info as does the general contractor (if you need one) and the framer wants to know where the heating ducts will go and the main plumbing runs so he can make things easier for the other trades people (i.e. collaboration).  This process will also force you to really think through your remodel details and i guarantee you will find things you missed and answer questions you didn't think to ask so don't dish this process off to anyone else.  It is painful and time consuming, but you will be glad you did it yourself.  SO, do you need to know software architecture and prototyping? No.  Would it help? yes.  Do you need a 'general contractor (i.e. CTO)? no, would it help? yes.  Can you manage the project on your own? Yes.  Will it pay to learn to write code and develop the entire product yourself? Probably not.  If you are on a tight budget can you hire a "generalist" and get by? yes.  I would retain the services of at least a technical advisor (i.e. inspector or your GC brother-in-law) to help with reviews and basic do's and don'ts and 'best practices with an eye to scalability, maintainability, supportability, and usability.  The bottom line is you need a bathroom so get it built, but first YOU need to know the customer's real needs and YOU need to do your homework if you hire a contractor.  DON'T farm out the process of wire-framing, use case and story development and screen mockups, but if you need help find helpers.  YOU need to force yourself to think through all of the details and processes and use cases.  One thing that may help with mind set is to approach the wireframes, screen mockups, use cases as though you were speaking to someone who's first language is NOT english.  Don't assume that they will know what you mean - explain it.   You may end up outsourcing some development to someone who doesn't speak english as a first language.  even if you don't, everyone who you work with will be better off.  The other benefit is that when you talk to/interview CTO/contractor/programmer/designer candidates they will see that you know your stuff and you set yourself apart from 95% of other non-tech CEOs.  If you have the budget you should consider hiring a "general contractor" (CTO) who can do some of the building and hire/contract out other parts. Consider also hiring a designer.  sorry for the long post. 

Lawrence Lerner Digitalization and Transformation Coach

August 12th, 2014

Start with a simple set of workflow diagrams. You can then hand draw the screen and put the basic information you need/want on each screen.

Tools such as OmniGraffle or Visio make this easier if you already have them. If not, whoever you have do the development should have tools like that. 

Ping me off list and I can send you some examples and talk you through the process. I do this as part of facilitated workshops with business users all the time.

Sam McAfee Building better technology leaders and teams

August 15th, 2014

I'd have to disagree with the folks who suggest prototyping and mocking it out yourself first. From my perspective, that's several steps too early. Start with customer development.

It's not just that you're designing an in-house tool--you're building a business (or at least I inferred that from your question). Building the software to solve a known pain point in a customer segment that you already have access to is not your biggest risk. Selling it into that market is! It doesn't matter what the UI looks like if you can't sell. You need at least stab at a business model (a light sketch like a business model canvas will do), and you can only really get that if you truly understand the problem you're solving, not just for the users, but for the buyers and deciders in the market that are not the user. What problem do you solve for them, that will have them write checks?

Your other challenge is avoiding bias because you're building the product "for yourself". It can be tempting then to skip customer development and build it how you'd want it to work. But you really should engage other potential users first in order to really understand their pain points. Make sure with data that your experience isn't unique. Maybe there are assumptions you're making that other government workers don't. Be careful not to just design it for you.

There's plenty more, but that's where I'd start.