Why Steadysun chose WeWeb over a Django UI

The Context

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.

‍

‍

Possible Solutions

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:

• Would be too costly to build an MVP
• The company didn't have the product culture to design the interface

‍

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:

• I would need to integrate with their Django backend
• The underlying technology should be modern and scalable
• They could enrich the tool with their own proprietary plugins
• It should be possible to self-host the frontend (to avoid vendor lock-in)

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.

‍

Choice and Outcomes

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.

‍

‍

Why they would choose WeWeb again

At the end of the day, Valéry would make the same decision again for five main reasons:

• The ability to export and self-host the code generated by WeWeb means that Frogcast doesn't have to worry about being stuck with a tool or having to recode everything down the line. This is key for Frogcast's technical team. It means they can focus on developing and selling their core business value – the data and complex logic in their backend.
• WeWeb allows Frogcast to build all the features they need.
• Building with WeWeb is cost-effective.
• There is no show-stopping limitation to WeWeb. It integrates perfectly with Frogcast's external backend, and, when they want to code a specific feature, they can.
• Although there is a learning curve, business people with very little programming experience are now iterating fairly autonomously on the app.

If Frogcast is successful and the current tech stack scales as expected, Steadysun will consider building their own frontend with WeWeb.