The hard part is yet to begin. The idea must materialize somehow, it must shape into something visual and usable, something to be used by others too. And in most cases it must turn into something that can be sold as a product.

We use our experience to enhance our clients ideas, to translate them into the digital world's language, to shape them into something clear, concise, real and usable. Each time we work for a new online concept we try to be realistic but we also try to let ourselves carried away a bit by putting our own imagination at work. We try to bring a balance between the two for the best interest of our clients. We try to balance between the technical and commercial aspects of the future product.

When trying to put an idea on paper (it actually happens in many cases) we like to work close to our clients and together elaborate on the logical schemas, data flows or GUI mockups. Our client's on-the-spot feedback matters a lot to us and that is why we constantly welcome it as we are also trying to save time and money.

Even if a client brings an idea and a well formed specification set, we still perform a supplemental analysis on certain elements like "strength", "weakness", "oportunities" and threats", as a part of our Agile Development work methodology.

Sometimes we are asked specifically to do SWOT analysis and to evaluate the placement of a new player online.

Guided by our own experience in the field and by the client's goal, we analyze similar products already existent in the market, the pros and cons of the future system. We also try to forsee any major changes that might happen in both success or failure scenarios.

You may have a very precise goal but the way to reach it is very important as well. The many existing web technologies and programming languages, web servers, application servers, databases, software licensing, make a tough choice to the client on many occasions.

During our discussions with the clients we constantly try to use simple words to explain the pros and cons of each available technological option, sometimes debunking their opinions.

• Who will develop the application and what's the level of his/her skills?
• What's more important: is it shortening the product's delivery deaadline or is it the overall quality of the system?
• How flexible is the project's purpose, how many things are subject to change as time goes by?
• How is this product going to be approached from the commercial point of view?

If we are physically close to each other then we use paper and colored pencils. If not then we use whiteboards or remote desktop sharing tools like Teamviewer or Skype's Screen Sharing option.In any given situation we know how important it is to an idea into a logical schema or an interface layout.

It's quite amazing to see how fast a software product analysis goes forward when all these sketches and mockups come in place. On his side the client starts being much sharper explaining his idea while on the other side, with each step, the tech analyst, the designer or the programmer start asking more relevant questions or even come forward with new ideas and improvements.

It's not about a complete design. It's only about getting a visual, schematic representation of the future system's key elements so that everybody involved in the project get a clearer image of what needs to be done, how much time will take, what kind of resources will be required and so on. In fact we strongly avoid giving price quotations for any new project before seeing its GUI mockups. Without them there's a high chance of guessing the wrong budget.

From the very start we consider our product is going to be a succesful one. A great success. This means proper technical solutions to support a large number of users (of course, when talking about web applications) and tight security measures.

Starting with the product analysis phase we try to send the necessary requirements to the development team, in order to ensure a secure and scalable system environment:

• We search, we request and we perform automated benchmarking tests to evaluate its capabilities (for example running a multiple simultaneous access stress test).
• We choose the proper technical solutions to protect the application against malicious access attempts or known threats that have become so badly familiar in the nowadays web based environments.

The choice we made two years ago, to walk the path of the Agile Development concept, taught us a lot more than book theory. And we can keep talking for days about project planning.

Yet shortly this is what we use to do:

• we split the project into as many parts as we can, parts that need to be implemented and interconnected in order to make the project work perfectly.

• if a particular specification takes longer than two weeks to develop, we split it until we end up with elements that can be delivered in a week's work time.
• as soon as we finish working on a spec we start asking the client for an evaluation.
• then we re-evaluate the whole plan.

Our project planning is a living process itself. We constantly come back, review what has been done so far and what still needs to be done. We are honest, direct and prezent while trying to deliver usable, fully functional software applications. And this type of project planning actually works very, very well :-).

Tough stuff. You don't want to end up spending your own money to finish the project and you don't want to ask the client to spend more of his money either. The truth is that there are very few software projects (same as in the constructions business) that do not end up exceeding their previsioned budgets.

We are no exception to this rule. But we have learned a lot and our experience helps us correctly evaluate things so we keep our project within the client's budget boundaries:

• We do not develop more than is needed, for any of the project parts.
• We carefully plan the activities and the features that must be delivered (see Planning).
• We know the hourly work cost of our services
• We ask the client about his budget, from the very start.
• You could never be able to build a plane when you can only afford a bycicle.