Cost Advantages of React Framework-Driven Development

Developing an enterprise-class SaaS application from scratch is a big undertaking with many separate aspects. When trying to cost out such a project, it is necessary to have a solid idea of what you are building.

My own approach is to visualize, in great detail, how the finished system might look, and then drill down into more details of the key subsystems to try to identify areas that might trigger unexpected additional work and higher cost. Outputs from this visualization process include a rough data model, UI wire frames, and a technology stack, including an inventory of potential third-party packages. This process is often referred to as design. :)

One consequence of this process is that many assumptions must be made along the way, particularly if you are trying to estimate costs. There will be assumptions about the data model, the UI/UX and interfaces to external systems. There will also be assumptions about the technology stack, and many qualitative decisions that will involve tough trade-offs. Often, these qualitative decisions are scope constraints, as they are intended to reduce cost. The Lean Startup approach advocates constraining scope in sometimes ludicrous ways to produce an MVP.

When presenting a proposed design and its consequent cost estimates, it is a good idea to explicitly state underlying assumptions. The cost breakdown can be presented to stakeholders as a list of stories and their respective assumptions, along with estimates. For example:

• Story X estimate story points S is predicated on the assumption that feature Y will be extremely rudimentary and will NOT do behavior Z.
• Story X will be implemented indirectly by third-party component Y and will therefore have all of the shortcomings of component Y, many of which may be ameliorated by subsequent development efforts at additional cost.

One of the biggest dangers that arises when trying to estimate costs is overlooking an important subsystem or behavior and therefore failing to supply any corresponding cost estimate. In my view, one of the key benefits of using a framework such as VXFrame to develop greenfield SaaS applications is that the baseline system serves as a kind of checklist of features and subsystems that is very tangible. You install the framework and then allow all stakeholders to explore it and review it. Once everyone understands what the framework does out-of-box, you can begin to build a set of stories which express the differences between what the framework does and what it should do.

For example, a stakeholder might assert we need something exactly like the baseline tenant and domain subsystem, but that allows external systems to manage the information via an API. In such case, the story need speak only of the creation of that new API, which is a finite development effort that can be estimated with great precision, compared to the much larger, risky effort that would be required to develop the entire tenant and domain subsystem from scratch.

I tend to think of such stories as deltas (differences) between framework (baseline) features/behaviors and desired features/behaviors.

In short, a framework-centric approach to project planning involves authoring a set of stories which are deltas between out-of-box and expected behaviors. Such stories can be estimated with a very high level of precision, reducing project costs and risks.