Software Product Development Process at CodeTiburon

7 minutes

One of our models of cooperation is called Software Product Development. We mean ‘development’ in its broad sense, comprising all the stages of creating a software product, that is to say, it is synonymous with ‘full cycle development’. Here we’ll explain what full cycle software development process at our company looks like.

With projects having a shorter time span and a defined scope of functionality that is unlikely to change during the development, we can provide a precise estimate of cost and time. In case of uncertainty, or if flexibility is needed because the requirements may evolve, it will be safer to go for Agile and, consequently, T&M model.

Regardless of a model, the first phase of our collaboration with a client – Presales – is the same. Here are the steps we take:

  1. Examine the Request for Quote (Request for Proposal) and get back to you to clarify project requirements.
  2. Provide a ballpark estimate.
  3. If suitable, discuss the model of cooperation and recommend a pricing model.

Next, there are two scenarios: Waterfall (Fixed-Price model) and Agile (Time and Materials model).

SPD Presales

Our approach to fixed-price contracts for software development

In order to provide our client with a clear understanding of what results he or she can expect, at what cost, and within what timeframe, we need to elicit all requirements and prepare documentation at the very beginning. That’s why we divide our projects into two stages: Project planning stage and Project development stage.

SPD Waterfall

Project planning stage

The first one involves working out detailed requirements and visualizing them through wireframes, data flow diagrams and even clickable prototypes. Next, we provide the client with a detailed estimate.

Throughout this phase we closely collaborate with the client. Our first aim is to see the whole product and identify the set of top-level real business requirements. Then, as each component piece is worked on, relevant, real business requirements need to be driven down to more detail so that responsive product requirements can be defined.

By the end of the project planning stage our clients receive:

  • Software Requirements Specification.
  • Wireframes.
  • Design concept.
  • Work Order which includes detailed project estimate, a project plan, technical requirements, acceptance criteria.
  • Development team.

Since this stage involves a large amount of work, it’s paid separately.

Project development stage

When all terms are negotiated and the Work Order is signed, we proceed to the next stage:

  1. We engage in the actual design, development, and testing of the software product.
  2. We deploy the product to staging environment for user acceptance testing (UAT).
  3. We deploy the product to production environment.
  4. After the release, we offer a month-long warranty period.

UAT begins with a build delivered to the client. At this point, the client can review the product and send us the first feedback. Often clients want addition or alteration to the initial product requirements. Such a change may involve an additional feature or customization or extension of existing functionality. A change request is a formal proposal for adjustment of some product or system. Because change requests are beyond the scope of the agreement, they generally mean that the client will have to pay for the extra resources required to satisfy them.


Why do we need Agile?

Since we have such a straightforward development process as described above, why do we need to implement Agile approach to software development?

Because a large number of our clients can really benefit from Agile. Early and continuous delivery of valuable software, continuous integration, daily meetings, changing requirements, even at later stages of development, are things that came out of the Agile space.

Waterfall methodology relies heavily on initial requirements. All project requirements should be written down in SRS during project planning stage. But this approach doesn’t take into account the evolution of project’s requirements.

Especially, when we are talking about startups. The main aim and challenge of any software startup is bringing a new idea to the market. The key concept here is verification of the initial idea and discovering a sustainable, profitable and successful product.

Due to the fact that at the beginning founders have only an idea, the process of product development includes a lot of assumptions that need to be implemented and evaluated as soon as possible.

Characteristics of Agile development approach

Agile came about as a solution to the disadvantages of the waterfall methodology. As opposed to waterfall model, where the product is delivered at once, at the very end of the project, Agile lets a client see and influence the product’s evolution.

We start from requirements analysis and planning, which ends with a Product Backlog and a Roadmap. After that we engage in a series of self-contained iterations (Sprints) with their own planning, analysis, designing, development, and testing procedures.

By the end of a sprint, our clients get a tangible result. They can make changes, introduce new ideas to the project and control the process in full.

Iteration Zero

Sprint 0 (or Iteration 0) begins with a kickoff meeting, where all the parties meet – the team, the management, the domain experts, and the stakeholders. We set out by exploring the initial business idea, technology, architectural goals, and study development practices. We also discuss critical dates. Our vision is transformed into estimated Backlog items (user stories). That serves as the basis for the ballpark estimate and a release plan. It’s crucial to work towards a common understanding of a project’s goals and keep in mind the product needs, which serve for priorities. After we have worked out a shared understanding of the definition of done, the actual development starts.

Iteration Zero


Next we get down to iterating. Each sprint (2-4 weeks) starts from a planning meeting, where the team examines the user stories from the top of Product Backlog, identifies Sprint Backlog tasks and selects how much to commit to deliver by the sprint’s end. To improve progress tracking and individual commitment to team performance, Sprint Backlog tasks are estimated in hours by direct implementers: software developers, testers or designers.

Each sprint ends in delivering some functionality, i.e. a product increment corresponding to the definition of done.

The remaining items are backlogged for the following sprints. That is followed by a review and prioritization of the Product Backlog.

We estimate user stories (Product Backlog items) in approximate, relative units – story points. This allows us to make high-level forecasts about how much will be done by when.

Throughout the development, the team works as a unity and there’s a regular feedback on the progress. A burndown chart shows the decreasing amount of work.



When the desired amount of product features are designed, coded and tested (according to release plan, roadmap), the team starts a release process. This process begins from a freeze, in which all work on adding new features is suspended, shifting the effort towards fixing bugs and improving the source code.

We are big fans of version control and GitHub, and use branching to alleviate delays in development caused by freezes. The project repository has a “release” branch from which new versions of the software are released to “production” branch, and a separate “development” branch in which the developers add new code.

The freeze applies only to the “release” branch, and developers can continue their work on the “development” branch.

We build and deploy release code to the staging environment, in order to test and verify the product version.

To conclude

The goal of our Software Product Development model is to create a reliable product that meets the client’s expectations and industry standards.

Our approach lets us choose the best possible software development process for your project.

Did you enjoy the read? Was it useful? Your sentiment helps us to create better content. Use the reactions to assess the article. Or leave us a note in the comments. We are out here to boost your tech savvy.
4.8/ 5.0 rating (45 votes)

Leave a Reply

newest oldest most voted
Clever Fox

Thank you for the detailed overview!

What non-agile methodologies have you considered?

Olga Yatskevich

Thank you for your feedback! The waterfall approach described above is one of those non-agile methods of software development. We use it extensively with the projects that are a good fit.