Why Hubql solves software collaboration challenges?

Building software today has become increasingly faster than just a few years or even a few months ago thanks to 3 major developments the rise of developer tooling, no/low code movement and integrations.

Rise of developer tooling

In past years and especially months, we have seen an increasing number of developer tooling being available to engineers to make their life easier, more efficient and enable them to implement functionality at even greater speeds.

Many of the tools are available for free as open source or partially as commercial open-source with additional tooling and time saving for paid or managed services.

These tools are available across different layers or roles of today’s software, from data, UI, business logic, deployment and operations to serve not only developers but also related roles.

Designers and UI Engineers can use Figma, Storybook or Tailwind to speed up their work and feedback loop.

Engineers can use AI e.g. GitHub Copilot or other tools to increase their velocity alongside many other tools that help to reduce manual work and automate repetitive or annoying routines.

Tools speed up implementation but not development process

Many of these tools enabled engineers to increase their speed. Still, at the same time, the tooling is very fragmented, especially open-source tooling typically solves just one problem at a time. Engineers end up with a multitude of tools (higher quantity) and increased complexity or learning curve for newcomers to understand the tool stack.

In today’s bear market economy, companies are increasingly looking for optimization and efficiency rather than adding more resources or tools with increasing costs.

While speed and accessibility to tools have improved, development velocity is now much more dependent on collaboration and the development process itself such as unblocking developer to gather feedback and business requirements.

Even though we have automation or AI to help us with the implementation, we still need to know what to build and understand what the right solution is.

No/low code movement

In recent years, developer tooling has exploded in size and VC funding. We have also seen a movement to enable employees other than engineers to contribute, build and launch applications.

This has been mainly enabled by no or low code tooling becoming available for software stakeholders, marketing teams and other teams to build and maintain their own applications.

Many no-code tools are helpful for building proof of concepts, internal applications or non-critical software with lower requirements for flexibility or scalability.

Low-code downsides

Sadly some of the tools or applications built later will end up in engineers hands to be extended or transformed into actual applications at later stage when requirements can no longer be covered with the abstracted functionality in these tools creating noise and distraction in engineering teams.

This can be worse with low-code tools where pre-mature abstraction or fuzzy logic will have to be redone at sunk cost or often higher expense with the exact effects of build vs buy in some cases.

Both no code as well as low code tooling are excellent to speed up initially but also do not solve the challenge of building software faster as a cross-functional team.

Integrations & APIs

Any software today, especially when starting as a startup or SaaS development, will be sped up by integrating existing libraries or APIs that solve everyday problems when building software, such as authentication, payments, and e-commerce functionality, to name a few.

Also, software is increasingly dependent on integrations with other systems to either send and share data across to other systems for reporting purposes or cross-team communication. None of the software vendors today even builds just one product but many applications for each use-case that are either well integrated or packaged together, but they are hardly enough to cover today’s business workflow hence the need to integrate with other systems and vendors.

iPaaS to the rescue?

As a result success of today’s SaaS heavily depends on integration capabilities, i.e. enabling users to connect to other systems (iPaaS) and proper APIs for their service, which stops many companies from scaling or onboarding larger customers.

iPaas systems are becoming increasingly available and common. Still, they often solve only integration pain points for publicly available APIs and common system integrations but sometimes fail to cover custom integrations, business logic and end up writing the gap between no-code, low-code and engineers writing custom integrations for internal or undocumented systems.

Good APIs today are scarce, and honestly, there is probably only a handful APIs that come to engineers mind that have really solved the pain points of both engineers and stakeholders with true API-first products being available for full satisfaction, such as Stripe, GitHub or Slack but the vast majority today either has an API but not well-documented, maintained, outdated technology or hard to use or worse not publicly available or not available at all.

Engineers are stuck today diving into outdated documentation, confused by weird API choices or waiting for support request to clarify fields or business logic in APIs to be integrated with.

In short, even software depends heavily on integrations and 3rd parties today. Neither are companies up to speed to this requirement neither is there mature tooling available for companies to adapt this trend quickly.

Why Hubql?

All three trends (developer tooling, no/low-code, integrations) are useful developments to simplify software development and its accessibility across departments beyond engineering but collaboration in software has not improved or maybe even become more difficult with these developments.

A lot of challenges for engineers remain unsolved and problems or blockers for engineers to be actually or to become significantly more efficient have not been addressed yet.

At Hubql we want to solve these problems to help teams build software together.

Engineer's are loosing time

Engineers today spend a lot of time on non-productive work or loose time today

in meetings,
waiting for clarification or requirements,
research of API documentation,
pending feedback from 3rd parties or API vendors,
and in code review.

All of these problems are hardly solved with tooling today and/or cannot be solve with just process but requires applications to solve them.

Even collaboration within engineering such as during code review is increasingly slow to grasp implementation details, the impact of changes and the lack of automation in this area.

The same applies to non-technical stakeholders in software which have become the bottleneck in software development in recent years with increased speed of implementation and developer tooling.

Non-technical stakeholders need to keep up with the speed of engineers in agile development workflows by providing quick feedback and getting insights into progress by themself to unblock engineers in their flow.

The software development process is broken with a heavy load on the speed of implementation by engineers but is actually being blocked in other stages such as research (vendor APIs), requirement gathering (data mapping), data modelling (feedback, impact analysis, visualisation) and code review.

How Hubql aims to solve software development pain points

Hubql wants to address the pain points of today’s software development by providing the tools and a platform for both engineers and non-technical stakeholders to collaborate better by increasing overall development velocity.

Our platform will provide the following core features to help tech teams achieve more:

Generation of data model visualizations in pull requests
Data model collaboration through comments and suggestions synced with your source code and code editor
Discussion and support platform across roles for both technical (code view) and non-technical users (visualization)
Sharing and collaboration with external parties to gather feedback for data models from consultants or freelancers
Enabling third-party API vendors to feedback and unblock engineers by sharing integration payload/API questions