Steadysun sells solar power forecasts and solar irradiance data. This data is precious to organizations that need to take into account meteorological variability in their own business, for example solar power plants that want to maximize their profitability. Their business is very hands-on. When a client needs data, they ask the Steadysun team to send it to them.
In 2021, Steadysun decided to develop a new B2B SaaS weather forecast platform – Frogcast – that would allow clients to request and access weather forecasts data on their own using an API.
The massive development of renewable energies such as solar energy is an essential lever for achieving the 2050 carbon neutrality objectives.
By creating the Frogcast brand in September 2021, Steadysun offers its weather forecasting skills not only to the energy market, but also to other sensitive weather players. Indeed, for a large number of economic actors, not anticipating weather conditions can have serious consequences in terms of planning, security and of course profitability. As a company, Steadysun already had the backend expertise and knew how to structure and manipulate the data for the app. But with no frontend developers and little UX/UI experience in their team, they weren't sure how to go about building the user interface.
Valéry Tarondeau, an Associate Director at Steadysun, took the lead on the project. Hiring a Django frontend developer to build the user interface of the MVP was dismissed right from the start for two main reasons:
Valéry, who had been monitoring no-code tools for a few years already, took a closer look with the SaaS platform project in mind. He had a clear set of criteria to make a decision:
In summary, Steadysun needed as much freedom as possible to build and scale the Frogcast UI on top of their existing tech stack. Bubble was dismissed because, although you can connect external data sources, it is monolithic by design and built with aging technology. Considering this, Valéry anticipated performance issues that could hurt Frogcast's chances of scaling. He tested younger no-code tools like WeWeb, Wappler, Ycode, Code2, and Buildr.
In the end, Valéry chose WeWeb because he was able to talk directly to the team. They discussed Frogcast's technical requirements, the features that were missing in WeWeb, and how long it would take to build an MVP. After receiving assurances that the tool could handle their specifications, Steadysun started to build the interface with WeWeb. They were mostly autonomous and, when needed, could call upon the WeWeb team to provide guidance or specific training.
WeWeb was able to deliver missing features and improvements in the proposed timeline. For example, "for loops" in no-code workflows and token-based authentication. Steadysun was able to develop their own Vue.js components, and use them in WeWeb. For example, they built a highcharts wrapper for D3.js that was very specific to their core business need. After six months, they made the Frogcast MVP available to test users.
At the end of the day, Valéry would make the same decision again for five main reasons:
If Frogcast is successful and the current tech stack scales as expected, Steadysun will consider building their own frontend with WeWeb.