10 steps to getting the most out of external development

(Guest post by Riddhiman Das) For more than two years, I’ve consulted with more than 35 different organizations around the country on various software projects. These organizations have had very different development needs. Some of them were just an idea a solo entrepreneur was trying hard to get off the ground without any funding at…

Founder Friday is a weekly guest post written by a founder who is based in or hails from the Silicon Prairie. Each month, a topic relevant to startups is presented and founders share lessons learned or best practices utilized on that topic. December’s topic is working with outside developers. 

About the author: Riddhiman Das is a software developer at biometrics startup EyeVerify and co-founder of software consulting company Galleon Labs.


For more than two years, I’ve consulted with more than 35 different organizations around the country on various software projects. These organizations have had very different development needs. Some of them were just an idea a solo entrepreneur was trying hard to get off the ground without any funding at all, while others were for Fortune 500 companies with a lot of experience working with outside developers and agencies.

Through my participation in these projects, I’ve learned a lot about how to effectively manage a development project when you’re contracting to a developer or a development team that’s not internal, and more importantly, how not to manage such a relationship.

Here’s what I’ve learned:

1. Have a clear idea of what you want

The first step before engaging with any developer or development agency is to develop a clear idea in your mind about the product or service you’re trying to develop. It’s important to be able to present a very quick summary of what you’re working on, yet at the same time being prepared to delve into the nitty-gritty of any individual section.

2. Think through special/edge cases

Solutions to whatever problem you’re solving are not usually a straight line. Have you walked through all possible scenarios and figured out how the system will react? Have you thought about invalid situations, when the user provides incorrect input or misses a step?

3. Develop a comprehensive requirements document

This is an important step a lot of people seem to ignore. Being able to articulate your concept and present it in written form is not only essential to the developer(s), but also helpful to understand your own product as well. This can be in one or more of many forms: user stories, “system shalls,” wireframes, etc.

In any event, it’s very important to ensure this document covers the purpose and scope of your product or service, identifies the user demographics, elaborately presents functional and non-functional requirements, and identifies all assumptions and constraints. An ideal requirements document also includes a proposed timeline with appropriate milestones, a testing plan and anything else you might think is helpful for the team to be aware of.

This is the single-most valuable resource for your development team, internal or external.

It’s also essential to remember this is continuously a work in progress, and will be revised as additional information becomes available. It’s not a big deal to change it as long as proper procedures are followed, but the earlier the changes happen, the better and cheaper it is.

4. Research several companies

Identify their strengths and weaknesses. Ask about their core areas of expertise and request to see work samples. Learn about how they approach software development. Are they fans of a particular software-development process methodology? Have they used their recommended process on previous projects? What were some of the biggest challenges? Figure out what kind of software consulting firm they are.

5. Know your expectations and learn about theirs

Before signing a contract with a company, state your expectations about the project precisely. What is your criteria for a successful project? How much wiggle room is there with the timeline? How often do you expect status reports? Who will be your point of contact? How soon can you expect a response to an e-mail sent to this point of contact? Do you expect them to comment the code in a certain manner or maintain a development log documenting technical decisions?

It’s also important that you ask what their expectations are from you. Do they expect you to be at bi-weekly scrum meetings? What kind of deliverables are required out of you to keep a smooth flow going? Are they developing a throw-away prototype for an MVP in an effort to get it done quick, or is this going into the final product?

6. Define the scope of each phase of the project well

It’s important to have the scope of each phase of the overall project defined precisely, and this is often dictated by other factors. What would the stakeholders (potential/existing customers) most want to see earliest? Sometimes the marketing plan dictates this to some extent as well. Also, sometimes two or more different entities work on a project. Maybe there’s a creative/digital agency developing the user experience and a back-end development firm working on the business logic. In such instances, it’s important for the client to identify in precise terms the scope of each of those sub-modules of the project.

7. For existing projects, make sure the team knows all the assumptions made by the previous developer(s)

Although starting a project from scratch is every developers’ dream, that’s often not the case. In such instances, it’s important for the new development team to be aware of the technical assumptions made by the previous team(s). This reduces ramp-up time for the new team and greatly diminishes the risks associated with the project.

8. Find a technical mentor not associated with the development company

If you’re not very technical yourself, it’s very advantageous for you to have a technical mentor you can bounce ideas off of. Sometimes, when the development team presents you with a few technical options that will achieve your desired goal, it’s a good idea to sit down with your mentor and discuss these so you have a different and perhaps more educated perspective guiding your decision.

9. R&D is more expensive than engineering

If your product or service requires original research and development, it’s going to take longer than an engineering solution that relies on existing research. R&D involves multiple cycles of hypothesis and exploration; design, development and testing; implementation and improvisation; and dealing with a lot more uncertainty.

10. Notify of changes to the requirements, scope or timeline immediately

From a developers perspective, it’s always better to know immediately of any changes to the project sooner rather than later. The sooner a change is identified, the cost to deal with the change can be remarkably minimized.


About the author: Riddhiman Das writes code. Currently he works at EyeVerify, where they are commercializing a software-only, biometric method for verifying the identity of mobile users. He also consults through Galleon Labs, a software consulting company he founded, that is based in Kansas City. He graduated from the University of Missouri-Kansas City and has been programming since he was 9 years old and couldn’t see himself doing anything else.


test form kevin

This story is part of the AIM Archive

This story is part of the AIM Institute Archive on Silicon Prairie News. AIM gifted SPN to the Nebraska Journalism Trust in January 2023. Learn more about SPN’s origin »

Get the latest news and events from Nebraska’s entrepreneurship and innovation community delivered straight to your inbox every Wednesday.