While most organizations are still debating whether to deploy their software in the cloud or self-host on their infrastructure, we're leaping several steps ahead. In the next few months, we're launching Global Huly – a revolutionary platform that will fundamentally transform how people collaborate. And that's just the beginning. Our ultimate destination? A fully decentralized, blockchain-powered collaboration network that will make traditional deployment choices obsolete. Let's explore this journey from today's solutions to tomorrow's revolution.

The Present: Cloud vs. Self-Hosting – Debunking the Myths

Today, Huly offers both cloud and self-hosted solutions, with our entire source code being open and accessible. While this gives organizations maximum flexibility, it's crucial to understand the real implications of each choice.

First Self-Hosting Misconception

Many organizations assume self-hosting is more economical. Our data tells a different story: Among our 30,000 cloud workspaces, only 2-3 have grown enough to exceed our free tier limits, requiring the modest $19.99 monthly subscription. That's just $239.88 annually for your entire organization.

The hidden costs of self-hosting often go unnoticed:

• Initial setup time and complexity

• Ongoing maintenance and updates

• Backup management

• Infrastructure costs

• Integration challenges with services like GitHub and Google

In fact, the initial setup alone can cost equivalent to five-ten years of Huly Cloud subscription. When you factor in the economies of scale – where our team can update 30,000 workspaces in the same time it takes you to update one – the economic argument for self-hosting quickly dissipates.

Integration Challenges and Solutions

While self-hosting Huly is entirely possible, integration with third-party services requires additional effort. Take GitHub integration, for example. It requires registering your own GitHub application and configuring endpoints – a relatively straightforward process. However, integrating with Google services can be more complex, potentially requiring software certification and penetration testing with approved companies (though workarounds might exist for single-company usage).

Despite these challenges, we know of several teams who have successfully integrated GitHub with their self-hosted Huly instances. The code is there; it's just a matter of documentation, which we're continuously improving.

Looking ahead, as we introduce AI features and Huly MetaBrain, self-hosters may face new challenges, such as the need to rent latest-generation Nvidia GPUs or manage high-end GPU clusters that would be difficult to utilize efficiently 24/7.

The Near Future: Global Huly – Breaking Down Organizational Barriers

But we're not stopping at traditional cloud solutions. In the next 3-6 months, we're launching something revolutionary: Global Huly. This isn't just an upgrade – it's a complete reimagining of how people collaborate across organizational boundaries.

Why Traditional Architecture Isn't Enough

Current cloud solutions, including our own, use multi-tenant architecture that isolates workspaces. While some market this isolation as a security feature, we recognize it as a limitation. Why? Because real-world collaboration doesn't respect organizational boundaries.

The reality is that 99% of users don't work in isolated workspaces. Whether you're a freelancer, agency, or huge transnational corporation, you always collaborate with people outside your organization. You have vendors, contractors, outsourcers, clients, users, and various other external partners. The current model of isolated workspaces creates artificial barriers to natural collaboration patterns.

The Global Huly Vision

Imagine a world where:

• Your identity is truly yours, as permanent as your email address (e.g., john.smith@huly.me)

• You can collaborate with anyone, anywhere, instantly

• Workspaces become fluid, lightweight containers for collaboration

• All your information is accessible in one place, yet perfectly organized

The current landscape of cross-organization collaboration is surprisingly limited. To our knowledge, Slack stands alone in attempting to bridge organizational boundaries with their "Shared Channels" feature, which allows two separate workspaces to connect for chat communication. While this is a step in the right direction, it addresses only a fraction of modern collaboration needs – just chat.

Think about your daily work: you're not just chatting. You're collaborating on documents, managing projects, assigning tasks, tracking deadlines, and coordinating complex workflows. At Huly, we're breaking down these barriers across the entire collaboration spectrum. Whether you're working on project timelines with your contractors, sharing documents with clients, or managing tasks across partner organizations – everything should flow as seamlessly as if you were all part of the same organization.

This isn't just an incremental improvement; it's a fundamental reimagining of how organizations and individuals can work together in the digital age. While others are building bridges between isolated islands, we're creating a continent where boundaries become meaningless.

The Future: Huly on Blockchain – The Ultimate Evolution

But even Global Huly is just a stepping stone to our ultimate vision. We're building toward a future where Huly becomes a truly decentralized, community-owned platform.

The Path to Complete Security and Trust

Security remains the one legitimate reason for self-hosting today. We acknowledge that Huly engineers potentially can access data in Huly Cloud, and this doesn't change with Global Huly. For organizations dealing with sensitive commercial secrets, this is a valid concern.

However, implementing Global Huly presents unique challenges that can't be solved with traditional approaches, especially when it comes to infinite scaling. This is why our architecture is evolving to incorporate blockchain principles, as blockchains are inherently designed as globally distributed databases.

Our roadmap includes:

1. Launching Global Huly with initial blockchain components

2. Implementing end-to-end encryption across all workspaces

3. Eventually transitioning to a fully permissionless blockchain

While we control the infrastructure and don't need a full-featured permissionless blockchain, our components can already include end-to-end encryption capabilities. Once all workspaces are end-to-end encrypted, the traditional arguments for self-hosting – security, economics, and reliability – will become obsolete.

The Final Evolution: A New Kind of Platform

The next-next generation of Huly will be fully blockchain-based. This permissionless blockchain will ensure that nobody – not even Huly's creators – controls the platform. The infrastructure will rely entirely on community resources, with everyone becoming a type of "hoster," but not just for themselves – for the entire Huly World.

At this stage, the traditional distinction between Huly Cloud and Huly Self-host will dissolve, converging into a singular entity: Huly on Blockchain. This represents not just an evolution, but a revolution in how we think about software deployment and collaboration.

Conclusion: Join the Revolution

We're not just building another collaboration tool – we're creating the future of how people work together. From traditional deployment choices to a revolutionary global collaboration network, and ultimately to a community-owned blockchain platform, Huly is evolving to break down every barrier to human collaboration.

The best part? This journey has already begun. While you can still choose between cloud and self-hosting today, we invite you to think bigger. The future of collaboration isn't about where your software runs – it's about connecting people and ideas in ways that were never before possible.

Stay tuned for the imminent launch of Global Huly, and join us as we build toward a future where collaboration knows no bounds.

As our team at Huly moves towards supporting more interactivity between workspaces and enhanced communication tools, I’ve been interested to learn how small businesses and agencies are using the current version of Huly to manage multiple client projects. By understanding how these teams organize their workflows on Huly right now, we can learn how to better support these workflows in the future.

I’ve had the opportunity to connect personally with several entrepreneurs who’ve moved their teams to Huly, and was especially excited to speak with Ryan Luttrell, CEO and founder of Outside the Box. Outside the Box is a digital marketing, design and development studio based in Calgary, Alberta, Canada. Ryan’s team works with clients all over the world to deliver high quality websites, software solutions and digital marketing campaigns.

Above: Outside the Box co-founders Ryan and Victoria Luttrell

Ryan and I caught up about how his experience has been since switching to Huly, and how the platform has helped him and his team keep track of tasks, communicate with clients and stay organized with projects.

Life before Huly, and why switching to Huly was a “no-brainer”

Outside the Box is currently in an important phase of their own growth as they’ve evolved from a side project into a thriving digital agency with a steadily expanding client base. As a result, it’s become crucial for them to find a workflow management solution that can keep up with the dynamic nature of their projects. Keeping all the ships afloat in a fast-growing agency like Outside the Box is a daunting task, and I had to know how Ryan and his team were managing it all before they switched to Huly.

Ryan shared with me that prior to switching to Huly, his team was juggling a handful of apps to manage their work: Jira, Slack, Google Drive, and BambooHR, to name a few. Trying to keep things organized and synchronized across so many different tools came with a host of pain points and headaches. As Outside the Box grew in scale, a critical need emerged for a more comprehensive management tool that could bring all of their team resources together in one collaborative platform.

When Ryan came across Huly through a post shared by the PixelPoint design team, he immediately saw the potential in Huly’s all-in-one approach. “Huly is really young,” Ryan told me, “but it looks like it could replace a lot of the tools that we’re using.” Excited by the prospects for Huly’s future, he began switching his team over to the platform.

Configuring Huly for multiple client projects

Everything in Huly is managed through spaces, which can be configured with their own settings and permissions. Teams can build any kind of structure on top of this foundation, using spaces to organize their work depending on what they need. By granting permissions only to designated members for each space, managers can control access to resources within a single workspace. This enables various teams and projects to work together seamlessly on client projects without compromising privacy for sensitive information.

“The thing that’s made Huly stand out for us is the level of configurability,” Ryan told me. “I can build out whatever schema I want for any chunk of knowledge I want to store, and link it to anything else in the workspace. That alone has been a game changer for us.”

Outside the Box works with a wide range of clients, from tech-savvy companies to small businesses that outsource all of their digital needs to Ryan’s team. Some of his clients have Huly workspaces themselves, while others communicate with Outside the Box through external channels. I was fascinated to learn how Ryan has configured Huly to manage projects for clients with such diverse needs and communication styles.

“By default, we’ve made all of our projects private,” Ryan explained. “Then I’ve granted access to our team to everything in the workspace. For one of our clients, I’ve made an account for them and they have access only to their own project.” By adjusting the permissions settings for each space, Ryan is able to effectively safeguard sensitive internal information while still allowing clients to interact with their own project’s task tracker, documents and resources.

Ryan also works with one of his major clients through a separate workspace. “Our agency is leading their technical team, so we created an entire new workspace for them,” Ryan told me. “We actually have their entire company running on Huly now as well.”

How Huly’s all-in-one approach supports intricate workflow tracking

The same project management tools that have been used for years tend to focus on one niche capability — for example, Trello for kanban-style tracking, Notion for documentation, or Slack for messaging. While some of these apps offer add-ons, integrations and workarounds to accomplish other common work tasks, it’s impossible to manage dynamic and complex work processes with any single one of these apps. Instead, teams are left with no choice but to force their own processes to fit within a rigid structure, rather than adapting the tool itself to reflect their real dynamic workflows.

As an “everything app”, Huly integrates all the essential features a team needs into a single platform, seamlessly connecting them to enhance productivity and collaboration without the hassle of juggling multiple cumbersome tools. During my conversation with Ryan, I was encouraged to hear that this approach has been instrumental in keeping Outside the Box on track with their client projects.

When I asked Ryan which feature of Huly his team found most useful, he spoke about this interconnectivity of the platform: “The most valuable tool has been being able to link an issue within a conversation, or having conversations around a specific issue,” Ryan shared. “We love this feature because it helps contextualize the conversation.”

Ryan also mentioned that his team is already migrating from Slack to Huly, and once the mobile app is available this interconnectivity will make switching to Huly the clear choice over competitors.

Paving the way for the next generation of Huly

While Huly has already established itself as the go-to platform for all-in-one project management, the current product offers just a glimpse into the promising future of the next generation of Huly.

Teams are already leveraging Huly to manage client communications, but some challenges remain. For example, Ryan’s clients might reach out through Slack, email or other external channels, which in turn requires someone on the Outside the Box team to manually translate that information into some kind of Huly object, such as an issue, document or internal team message.

The next generation of Huly will address these challenges by enabling global communication between users. Whether or not they are a member of a Huly workspace, users worldwide will be able to communicate smoothly through interconnected channels on the Huly platform. This advancement will open the door for teams to manage their work entirely within Huly, without the need to synchronize information across multiple apps and tools. “When you think about where this product is now and where it could be a year or two from now,” Ryan explained, “it’s a no-brainer to make the switch because it’s so advantageous to have everything in one place.”

This next generation of Huly, featuring a more comprehensive approach to information management and enhanced process tracking capabilities, is on the horizon. In the meantime, exciting changes are coming to the current Huly platform even sooner. As we refine our existing communication system and work towards completing our mobile app, teams are already beginning to enjoy enhanced chat performance and soon (in our upcoming release) will be able to connect with Huly from their mobile devices using Telegram. Huly users will be able to receive and respond to messages and notifications right from their mobile devices, marking a significant step towards a promising future ahead.

“Huly is a young company that’s moving really fast,” Ryan remarked. “They have a vibrant community that their team is unbelievably responsive to. But most things just work.”

We’re as excited about Huly as Ryan is, and conversations like these help guide our team’s thinking as we move into the future of Huly. You can join in the conversation in our Slack group, and if you’d like to share your own story with Huly, feel free to reach out to me directly at abigail@huly.io to be featured in an article like this one.

I just had a mind-blowing experience that's convinced me: AI is going to revolutionize the venture capital industry, and frankly, we humans might be in trouble.

Let me set the stage. At Huly, we often get approached by investors, some managing billions. Recently, I've been avoiding these conversations. Why? Because most of these folks, despite their Ivy League degrees and fancy titles, often lack the deep understanding needed to truly grasp the complexity of what we're doing.

Huly: More Than Just Another Startup

Huly is more than just a tech startup. We have two facets to our business. First, there's the current Huly - a collaboration and productivity tool that's already available and loved by our users across various industries. It's designed to benefit everyone, from creatives to managers, and yes, developers too. But that's just the beginning. We're also developing the next-generation Huly, which is where things get really complex and exciting.

This next-gen Huly will be blockchain-based and aims to be an enabler of the remote worker economy. It's a multifaceted project that sits at the intersection of technology, user experience, product innovation, and economics. We have some exciting ideas from a product perspective that could revolutionize how people work and collaborate. We're not just building a product; we're creating an ecosystem. This includes the Huly Foundation, a non-commercial organization responsible for the governance of the Huly Project. You can learn more about the Foundation's structure and goals at https://huly.foundation/bylaws/.

The Communication Gap

Now, imagine trying to have a productive conversation about all of this - from our current product to our future vision, encompassing its broad appeal and technical complexities - with someone who has a limited understanding of technology and how diverse teams collaborate in the modern workplace. It's like trying to explain the intricacies of a symphony to someone who's only ever heard a single instrument.

Or picture this: you're discussing the blockchain architecture for our next-gen product, and an investor confidently suggests using ZK-SNARKs in a context where it's completely inappropriate. In the Web3 world, some investors throw around complex terms without understanding what they are or what they're for, much like how some VCs suggest "adding AI" to every product they see.

Enter the AI Investor

But here's where it gets interesting. I recently had the chance to interact with an AI in an investor context. And let me tell you, it blew my mind.

In just 15 minutes, this AI grasped concepts about both our current product and our next-gen vision that usually take me two hours to explain to human investors - and even then, understanding isn't guaranteed. It typically requires knowledge across different domains and significant experience to fully comprehend what we're doing.

But this AI? It understood everything I said, built a correct picture of our product ecosystem and vision, and even filled in missing information with its own thinking - correctly. Most impressively, it summarized everything in 20 seconds in a way that I couldn't have done better myself.

The AI Advantage

This experience made me realize: AI isn't just coming for coding jobs or customer service. It's coming for the suits in Sand Hill Road too. And honestly? It might be a good thing.

Think about it. An AI investor doesn't care about your Ivy League degree or your golf handicap. It won't be swayed by a charismatic pitch or a fancy PowerPoint. It'll evaluate your startup based on cold, hard data and the merit of your ideas, without throwing around buzzwords it doesn't understand.

The Investment Decision: Where AI Truly Shines

Now, I can already hear some of you saying, "Okay, maybe AI can evaluate a startup, but what about making the actual investment decision? Surely that requires human judgment?"

Well, let me let you in on a little secret: this is actually the easiest part of the process, and it's where most investors aren't even fully utilizing their brains. The reality? Most investors simply take your startup's economic data, plug it into a spreadsheet, and let Excel tell them whether it's worth investing or not.

This is precisely where AI would undoubtedly outperform humans. An AI system could analyze vast amounts of historical investment data, current market trends, and your startup's metrics in seconds. It could run complex simulations, consider countless variables, and provide a much more nuanced and accurate investment recommendation than a simple Excel formula.

Moreover, AI wouldn't suffer from the biases that often cloud human judgment - like favoring startups with ivy league founders or getting swayed by a particularly charismatic pitch. It would focus solely on the potential for success and return on investment.

The Human Touch Dilemma

Sure, you might say, "But what about the human touch? The mentorship? The network?" Valid points. But let's be real - how many VCs actually provide meaningful mentorship beyond introductions to their buddies? An AI could potentially offer more tailored, data-driven advice and connections, without suggesting you blockchain your coffee machine.

The Future of Venture Capital

Now, I'm not saying human VCs will disappear overnight. But I am saying that the VCs who adapt and learn to work alongside AI will have a massive advantage. And startups? They might finally get the fair, unbiased evaluation they deserve, free from misused tech jargon and misplaced buzzword suggestions.

Of course, this raises bigger questions. If AI can do VC better than humans, what other industries are next? Are we looking at a future where AIs are not just our tools, but our bosses? Our investors? Our decision-makers?

A Revolution in Capital Allocation

It's a wild thought, and honestly, it's a little terrifying. But it's also exciting. Because if this AI interaction is any indication, we're on the cusp of a revolution in how we allocate capital and resources in our society.

So to all my VC friends out there: the AI revolution isn't just coming for the startups you invest in. It's coming for you too. The question is, are you ready to compete with an investor that actually understands what ZK-SNARKs are - and when not to use them?

The Current Situation

If you've ever tried to hire a software engineer, you've likely been flooded with resumes. About 99% of these describe the candidate's skill in Technologies X, Y, and Z, along with how many years they've worked. Candidates often explain how they helped businesses by using Technology X and fixing problems with Technology Y.

While this sounds impressive, most of these claims suggest that the candidates are mainly users of existing technologies rather than their creators. It's as if they're describing how they've mastered tools made by an advanced civilization, rather than building those tools themselves.

Of course, these candidates have some basic understanding of how the technology works. However, when asked deeper questions, many are surprised or even dismissive, arguing that such knowledge isn't needed for their job. This reaction raises an important question: what exactly are we looking for in a "software engineer"?

Most of these candidates have never built basic data structures like hash tables. If they've worked with complex algorithms, it was likely during college or on websites like LeetCode, just to get a job interview.

The Main Problem

There's now a clear difference between two types of jobs in our industry: technology creators and technology users. These roles need very different skills, knowledge, training, and ways of thinking.

The problem—and it's a big one—is that these two different jobs are mixed together under the single title of "software engineer." This mixing is causing many issues, starting with a broken hiring process.

Think about the car industry as an example. There are two different jobs: engineers who design cars and drivers who use them. Both jobs need different skills and knowledge. A car engineer might be a bad driver, while most drivers can't design cars. In software engineering, however, both roles are often called "software engineers."

This situation causes many problems:

• Companies needing software engineers (those who design the technologies) struggle to find them among the many "technology users" applying for jobs.

• To solve this, big tech companies have created tough technical interviews focused on algorithms and system design. While this helps them find engineers, it creates a new problem.

• Companies that actually need "technology users" often copy these practices without understanding why, effectively asking drivers to design car engines as part of their hiring process. As a result, they end up filtering out good drivers (whom they really need) and hiring mediocre engineers (whom they don't need at all).

• Many "technology users" feel they have to study advanced algorithms just to get jobs that don't need this knowledge, leading to frustration and wasted effort.

• Creators often end up in "technology user" roles, leading to disappointment or a move away from engineering.

• "Technology users" who get jobs at big tech companies often find themselves in roles they didn't expect or want.

It's crucial to understand that the vast majority of businesses actually need "technology users" (or "Drivers" in our car analogy), and this is entirely appropriate. Most companies require professionals who can effectively apply existing technologies to solve business problems, rather than those who create new technologies from scratch. This role is not only valuable and necessary but often more demanding in the industry, as it requires a broad understanding of both technology and business needs.

A Possible Solution

To fix these issues, the industry needs to officially recognize and separate these two types of roles. By clearly distinguishing between "technology creators" (those who create new technologies) and "technology implementers" (those who apply existing technologies to solve business problems), we can bring much-needed clarity to the hiring process and career paths in the industry.

Putting this distinction into practice would require changes in job descriptions, interview processes, and even education programs. However, the benefits could be significant:

1. More efficient hiring processes tailored to what each role actually needs.

2. Clearer career paths for both engineers and technology implementers.

3. Better matching between candidates' skills and job requirements.

4. Less frustration and more job satisfaction for both groups.

While this separation isn't always clear-cut, and there will always be some overlap between the roles, acknowledging the difference could go a long way toward fixing the current problems in the software job market.

Throughout this period of Huly’s growth and development, I’ve had the pleasure of connecting with several entrepreneurs and professionals who’ve moved their teams to the Huly platform, and I’ve been particularly interested in how teams from different industries are adapting Huly to their own unique workflows in their line of work. This concept of adaptability is at the heart of Huly’s development, and as our team continues to build Huly’s capability to adapt to any kind of workflow in any field, it’s encouraging to see such diverse teams already thriving on the platform even at this early stage.

Using Huly to optimize productivity for 3D printing

I was first introduced to Toucan3D — an Austrian startup developing variable line width 3D printing — when co-founders Thomas Seidl and Andreas Zapfl provided feedback on their experience with Huly in response to our user survey. I was immediately interested in their use case for 3D printing, a fast-growing industry requiring technical management of both hardware and software components.

Above: Toucan3D founders, from left to right: Thomas Seidl, Peter Waldert, Markus Müller, Andreas Zapfl

As I learned more about Thomas and Andreas’s work at Toucan3D, I began to understand why there was such a need in their industry for their project management platform to keep up with the complex and dynamic nature of their workflows. Toucan3D is revolutionizing 3D printing with their innovative solution to produce faster and stronger prints, using variable line width and advanced heating technology. Their printing process also prioritizes sustainability by optimizing material consumption and production efficiency, thereby minimizing waste and energy usage. Managing these complex processes in such a fast-paced industry requires a centralized platform for tracking related tasks and progress, organizing technical documentation, and managing dynamic workflows.

When I had the chance to catch up with Andreas to learn more about Toucan3D, I was eager to understand how Huly could support his team’s needs for both software development and hardware engineering. Andreas shared with me that Huly’s approach as an “Everything App” resonated with him — with the ability to manage everything in one platform, his team is able to optimize productivity in their workspace.

Documenting issue activity in Huly

Documenting changes to issues in the task tracker is absolutely essential to the Toucan3D team, and Huly’s system of integrating documentation with task tracking helps with maintaining and organizing important project resources. Teams in many different kinds of industries require detailed documentation of changes and updates, and it’s critical that any activity is recorded for later reference.

“When writing, working on and discussing issues, everything is documented,” Andreas explained. “This workflow is great because it allows us to create issues with attachments for multiple drafts, and we can easily include comments from colleagues.”

Because the Toucan3D team is working with both hardware and software issues in their workspace, having documentation capabilities integrated within their task tracker crucial for staying organized. Workflows related to code-based software projects can be tracked and documented right alongside those related to hardware, allowing for technical and non-technical issues to be managed together.

Connecting remotely in Huly's virtual office

Huly’s integrated virtual office space has also been particularly useful for Andreas and the Toucan3D team, allowing them to collaborate remotely without relying on an external video conferencing platform like Zoom or Google Meet.

“You can see who’s in their office and join in a meeting room,” Andreas told me, explaining how his team holds meetings in the virtual office while collaborating on wiki documents. “We can stay inside Huly and write [notes] while in the meeting.”

With screen sharing, full screen mode and the ability to pin the meeting to the side of the window while navigating the platform, Huly’s virtual office space makes it easy for the Toucan3D team to stay in sync while collaborating remotely.

Keeping track of conversations

Projects are not built in an empty void — just as important as internal team collaboration is building connections and relationships with outside companies, clients and contacts. In the not-so-distant future, Huly will allow for cross-communication between workspaces, allowing teams on Huly (or even outside Huly) to communicate with each other seamlessly without ever needing to leave the platform or rely on external software.

While this is a goal that we’re steadily working towards, it was important to us to provide a contacts management tool for teams using the current version. Our current implementation enables teams to keep track of their external communications right within the platform, treating contacts similarly to other objects in Huly and allowing them to be linked to tasks in the tracker.

I was excited to hear that Andreas found our contacts system to be exactly what he needed for managing communications with Toucan3D, even in this early stage.

During our conversation, Andreas described the challenge of keeping track of handwritten notes jotted down from a phone conversation. “With this system where you have all of your contacts in one place, you can simply open a person’s contact and start adding notes,” Andreas explained. “For example, if I have a phone call with someone, I can write everything that’s discussed so the rest of the team can see it. For employees, I can upload their CV and store everything in one place.”

Contacts in Huly can also be linked to issues in the task tracker, allowing teams to create tasks for follow-up calls or even structure entire projects around client contacts. This comprehensive approach to data management across the platform is part of Huly’s long-term development plan as we continue to build capabilities for interconnected workflows.

Enhancing personal productivity

Huly is designed as a tool for teams, but I’ve also connected with many solopreneurs, freelancers and coding hobbyists who are using Huly for independent or personal projects.

I was surprised to learn that even within the Toucan3D workspace Andreas’s favorite feature is one he’s using for personal productivity — the time tracking feature of the personal Planner.

Time tracking in Huly is another capability that is still very much on its way towards where we’d like to see it (and is therefore perhaps not yet capable for some use cases), but Andreas is already finding immense value in using the current implementation to stay productive. By assigning himself issues in the task tracker with the status “Todo”, Huly automatically generates an action item in his Planner; Andreas then uses the Planner to track the time he spends on each action item and compare it to how long he estimated it would take before starting.

“The connection between tasks and action items with the drag-and-drop calendar and time management is hands down your best feature,” Andreas told me. “The system tracks how much time I spend on a task across all the times I’ve scheduled it on my calendar and tells me the total time spent. I could have a feature I estimated would take two hours, but when I finish the task I can see that I actually spent seven hours total working on it.”

This capability helps Andreas see where he’s spending most of his time, adjust his estimations and plan work accordingly.

Where is Huly going from here?

Every time I’ve had the privilege to have a conversation like this one with Andreas, I deepen my understanding of how teams in other industries are managing complex workflows and I learn more about how Huly can help.

Our team at Huly is constantly working on developing new features and improving our existing capabilities to make Huly a truly comprehensive all-in-one solution for workflow management, powerful enough to replace traditional tools while helping innovators bring their teams into a more modern and progressive environment for growth. Learning from teams like Toucan3D helps guide our thinking as continue to develop our platform, and we appreciate the insight we gain from our community.

I’d love to hear what you’re building with Huly! You can join our growing community on Slack to connect with our team and be inspired by other users. If you’d like to share your own story with Huly, feel free to reach out to me directly at abigail@huly.io to be featured in a future article like this one!

You may have heard that humans share about 90% of their genes with mice. Mice are often used in medical research because many human genes have analogous functions in mice. Interestingly, humans even share a significant portion (about 60%) of their genetic material with fruit flies Drosophila melanogaster.

From an engineering point of view, this is both fascinating and expected. Our creators—whether they are the Universe, Gods, Aliens, or something for which we don’t yet have a word—engineered this world in a way that naturally involves sharing common functionality across species. Things become even more intriguing when you consider the exact numbers: Humans and mice share 90% of the same code and data to function.

If I were a science fiction author, I might entertain the idea that mice were created with the goal of testing and verifying some of the upcoming primate body functions and processes. Much like how mice are currently used in medicine to reverse engineer and test human body functions.

What is contained in those 60%-90%? The foundation of life. These are the basic building blocks for any animal life on the planet, defining all the complex processes necessary to bring an animal species to life. This foundation is the essence—it’s complex, super important, and barely visible, existing behind the scenes (or within the scenes).

Chapter II: SaaS Applications

In the software world, source code and data (models) play the same role as DNA in the biological world. Most of this code (DNA) is not directly exposed to the end-user; instead, this code has little to do with the application features. It forms the foundation of the application—the building blocks necessary to bring the application to life.

Typically, this code has many layers: starting with the infrastructure layer (servers, databases, etc.); the client layer (web, mobile, etc.), which deals with the infrastructure; various services (authentication, authorization, etc.); utility functions and frameworks (logging, error handling, reactivity, scheduling, collaborative editing, etc.); general-purpose UI components (such as tables); and finally, the domain-specific logic on top of all of that.

In a well-designed application, the domain-specific logic is just the tip of the iceberg. I wouldn't be surprised if a thorough analysis showed that only about 5% of the code is specific to the application domain (such as CRM, incident management, or user support systems). The remaining 95% of the code provides the foundation necessary to make the application work. If you were to ask the authors of a well-designed CRM application how much of their code they would need to transform their CRM into a user support system, the answer would likely be around 5%.

Of course, the actual answer might be different and more than 5%. However, if it is significantly more, it could be a sign of poor design or just a reflection of the Minimum Viable Product (MVP) stage of the app, which is not meant for production use.

Moreover, even at the domain-specific layers, every niche SaaS application tends to create the same parts of business logic. For example, you may find a "Task Management" module in nearly every niche application. This is common in CRMs, Applicant Tracking Systems, User Support Systems, and almost everywhere else. Typically, these modules are poorly designed and implemented because they are not the main focus of the application. They are just a side effect of the niche.

And finally all these niche applications typically integrates with same services: Google, Facebook, Stripe, Twilio, Slack, GitHub, etc.

Chapter III: Niche Applications Madness

The software world is full of niche applications. There are CRMs for real estate agents, CRMs for lawyers, CRMs for dentists, CRMs for plumbers, CRMs for software developers, CRMs for CRMs, and so on. The same goes for Applicant Tracking Systems, User Support Systems, and many other types of applications.

As discussed in Chapter II, authors need to rewrite only about 5% of the code to transform a CRM into a User Support System. Possibly less, as some business-logic functions (such as task management) remain the same.

I've been concerned about this for years: creating an application like a CRM to a production level and making it feature-complete so it can be used by real users is a massive amount of work. It may easily take a couple of years for an experienced team of highly skilled engineers. Many teams worldwide are currently on this multi-year journey (e.g., working on a CRM for plumbers or a "modern" CRM, whatever that means).

These teams are essentially wasting tens of man-years each to create 95% of the foundational/integration layer, then common functionality of CRM including task management, just to expose their niche features or "modern" ideas to the end users (which might be less than 1% of efforts if we speak about a plumber-specific CRM).

Why does this happen? Why has such madness become the norm? I think there are several reasons:

First, what I can probably call "Common Misconceptions." I've always been a "platform" guy, and since the '90s, I’ve heard from people of various expertise levels that it's "impossible to create an app that will handle all needs well." I still hear this from many people, and I can't understand their logic even after 30 years. The funny part is if you ask each of them "why do you think so," you'll immediately realize that most have never thought about "why"; for them, it's just a form of "common sense."

However, the reality, including the software world, is full, full of examples of products that perfectly handle the needs of different industries, workloads, niches, etc., in an excellent way. Moreover, the most used and most successful software in the world is precisely this kind of software. From Operating Systems, Databases, and Web Servers to Microsoft Office, Google Docs, and Slack, these products are used by millions of companies in different industries. Excel wasn't designed for accounting, but it's used by millions of accountants. Slack wasn't designed for software development, but it's used by millions of software developers. And so on.

Honestly, I still do not know any real reason why it's "impossible" to create software that will handle all needs well.

Second, Apple's influence. I believe Apple contributed significantly to this madness by creating an App Store. Remember "We've got an app for that"? This was a great marketing campaign, but it also created the "niche problem" we're talking about. I admire Apple, and Steve Jobs was a pure genius. He did everything right for Apple and the new mobile computing market they created. The mobile market was new and in desperate need of many applications and many vendors. And Apple needed them now. So attracting as many developers as possible to create as many apps as possible quickly was the right strategy, and Apple succeeded. However, it was a strategy for a new market, a new platform, and a new era.

Apple couldn't wait a couple of years for vendors to come up with serious, multifunctional apps for the App Store; having an empty App Store for a couple of years was not an option. They needed to fill it immediately. And they did it. But people started to believe that this was the correct way to build software in general. People began to think that every problem should have its own app. This mindset led to the proliferation of niche applications, many of which have no real reason to exist.

Third, I believe marketers love this madness and continue spreading this "impossibility" misconception, which is close to a "lie." It's much easier to sell a niche application than a multifunctional one. It's much easier to sell a CRM for plumbers than a CRM for everyone. It's much easier to sell a CRM than a CRM and also a User Support System. And so on. Or at least they think so (which could be another misconception). What is true is that the broader your audience, the more competition you're facing, possibly ending up competing with companies like Microsoft, Google, or Salesforce. So from that perspective, marketers will choose a niche market where they can "compete" without clashing with industry giants for market share.

Chapter IV: The Everything Apps

Let's define what I mean by "Everything App." This is very important for further discussion. A chess application bundled with a photo editor and a music player is not an Everything App. It’s a "bundle" of applications.

By "Everything App," I mean an application that shares a vast majority of codebase and infrastructure, as well as a lot of business information across different problems this everything app is designed to solve. For example, a CRM and a User Support System address different problems, but they share a lot of common functionality and business information. They share a user base, task management, notifications, integrations (calendars and mail), customer (user) information, and a natural information flow when a customer becomes a user and vice versa. They share a lot of things. And they can share even more if they are designed to be Everything Apps.

This is not a new idea, and this way of thinking was more common in the past, before the "we have an app for that" mindset and niche madness took over. Moreover, consider Rippling and its CEO's Parker Conrad ideas. What they are building is essentially an Everything App in the HR space. Parker is a guy who didn't buy into the "niche madness."

Rippling created an Everything App for HR, and it’s working well. Parker Conrad calls it a Compound Startup which is fine, but it's important to understand that "Compound Startup" is more of a business perspective. From that viewpoint Atlassian could also be considered a "Compound Startup" though their technical solution is far from being a well-designed Everything App. An Everything App is more about software design, not business design, and any startup developing an Everything App is inherently "compound" by definition.

So, why are Everything Apps better than Niche Apps?

First, developing Everything Apps is in orders of magnitude more efficient. As discussed in Chapter II, you need to rewrite only about 5% of the code to transform a CRM into a User Support System. This means that you can add a User Support System to your existing CRM app with 95% less effort than creating a support system from scratch. This is a huge difference, not only in go-to-market (GTM) time and effort but also in maintenance, support, and further development. Very likely, a bug fix will affect both "modules" simultaneously.

Then, let's add an Applicant Tracking System, software development project management, and other modules to our Everything App. The more modules you add, the more efficient you become. The more modules you add, the more you can share across them. The more modules you add, the more you can leverage the power of the Everything App. Finally, you might have 20-50 niche apps in one Everything App, spending just twice the effort compared to creating one niche app. This is a huge difference.

Second, integration. The current world of niche apps has made everything so fragmented and almost impossible to use as a whole system. You need to switch between apps, copy-paste information, re-enter information, and re-learn how to use each app. This is a nightmare. Therefore, integration among those apps has become essential, and there are many solutions to this problem.

People who think they can integrate two modern applications together are both right and wrong. Typical integration between two applications in 2024 is at a similar level to copy-paste functionality in operating systems from 1994. If you think about it, you'll realize that there are no real integrations; it's just workarounds. A typical "integration" assumes "copy-paste automation"—for example, if you create a customer in your CRM system, it will automatically appear in the User Support System when the customer becomes a user. Or some property changes in System A will trigger some action in System B.

I'm pretty sure that a very basic level of "integration" is what companies worldwide spend millions on. Many companies work on products to facilitate that, managers get huge bonuses, and there are a lot of presentations about "successful integration projects" going on. I believe CEOs are happy to know that the entire IT department completed an "integration" project I described in a couple of months. If you think more about it, it's crazy. Assume you have a well-designed Everything App. How much effort would you need to implement such a level of functionality? I would assign an intern for a single day's task to do it.

Integrating several niche apps to have consistent information about users/customers can be a nightmare. You need to use one app as the source of truth and somehow prevent any modifications from other apps, implement a custom shared database as the source of truth, or just forget about integration and force your employees to open one app for up-to-date information. This is a nightmare.

Third, synergy. There will never be real synergy between niche apps because they never work as a whole. Even with perfect "integration," you only automate information entry; instead of employees copy-pasting data or updating data because of some "events" in another system, it will be done automatically. But it will still be a set of isolated niche systems, so no synergy effect will emerge from that.

Think about the kind of synergy you can achieve in your business if you have a well-designed Everything App. I'm confident you'll find many opportunities. It's also worth listening to Parker Conrad's interviews—he talks a lot about synergy in his Everything App... sorry, Compound Startup.

Conclusion

To me, whatever you do, you should always aim to create an Everything App. This aligns with the nature of software development. Generalization and reusability are key concepts in software development. When building your next app, you should always consider what other problems you can solve with the same codebase and infrastructure at every layer of your solution.

That's why we initially envisioned Huly as an Everything App. Moreover, when we started Huly, we had no idea what types of apps we would create and for which industries. Huly started with a platform, a layer to develop virtually any SaaS application very efficiently. It was initially designed to be extended by plugins, and by plugin, I mean any big or small extension of the platform and the application. It could be a huge functionality for the end-user or just a button extending the UI of an existing application.

None of what I'm writing about are new ideas; many companies across different industries have proven that everything apps work well and are very successful. I already mentioned Rippling, which is a great example of an Everything App in the HR space. Software engineers might also remember Eclipse. I recall that in some documentation or blog post, the Eclipse Platform authors wrote that Eclipse is a platform for "Anything and Nothing in particular." And it was very true. Eclipse was also an exceptional example of an Everything App from a design and implementation perspective, demonstrating how to build a platform for an Everything App, how to reuse code, and how synergies emerge.

When relying on these common project management tools, team leaders are often left dealing with ambiguity in assigning tasks, redundancies in tracking issues, and difficulties with customizing the platform settings for their needs. Team members themselves lack clarity on their individual tasks, lose track of important details, and often find they need to use multiple applications and tools to manage their own personal workflows and scheduling. All of this contributes to inefficiencies that impede progress and stunt creativity and innovation — after all, who can focus on bringing value to their team when they’re struggling to plan and track basic tasks?

The Huly platform eliminates redundancies in project management and reduces blind spots that lead to human error by seamlessly integrating workflow tools with an individual task scheduling system. Huly builds upon the familiar structure of kanban-style platforms by introducing the Action Item, a representation of an individual team member’s contribution towards a project task. The Action Item, in combination with Huly’s powerful suite of familiar project management features, allows for a more accurate and dynamic reflection of real-world workflows, enabling both team leaders and individual team members to focus on delivering results without feeling impeded by redundant reporting or bogged down in the weeds of a complex tracking system.

Not just another to-do list

Whenever a task (we’ll refer to these as Issues) is assigned to a team member and given a status of “Todo”, the system will automatically create a corresponding Action Item in that person’s Planner. It’s then up to that team member to schedule a time to work on their Action Item, either by dragging and dropping it into their calendar, or by manually entering a time slot for it.

By scheduling the Action Item, not only will it move to the “Planned” section of that team member’s personal Planner, but it will also be visible to all team members on the Team Planner. This allows the whole team to see everyone’s tasks at a glance, without the need for a team meeting just to report on assignments.

Scheduling an Action Item automatically updates Issue status

Let’s step back from the world of Huly for a moment to consider a real-world workflow. Think about a small task like creating a login button on a landing page for a website. When is this task considered to be “in progress”? Is it when the team lead first decides this is something that needs to be done? Is it when the team lead communicates this task to their front end developer? In the real world, as far as the project is concerned, no progress is being made on that task until someone comes forward and says “I will do this task, at this time, and this is how long it will take me to complete.”

Huly applies this concept to the relationship between an Issue (a piece of work that needs to be done) and an Action Item (an individual’s commitment to actually do the work). When an individual team member schedules their Action Item, the Issue status is automatically updated to “In Progress” — no need for the individual to report this to the team lead, and no need for the team lead to hunt down the individual for an update — everything is seamlessly and automatically integrated.

By establishing this automated relationship between Issues and Action Items, Huly offers an alternative to existing project management platforms by creating a system that more accurately reflects these kinds of real-world workflows.

What’s next for Action Items on the Huly platform?

Huly is currently offering a lightweight version of the Action Item feature that teams can start using right away when they onboard with the Huly platform. Action Items are already integrated into the “Classic Project” template that all projects created on Huly use by default.

However, the Hardcore Engineering team is currently working on incredibly innovative features unlike those in any other project management tool. In future iterations, Huly will take the concept of the Action Item even further to improve automation for workflows and the offer enhanced features to completely customize the Huly platform to model complex processes. Teams will be able to break down projects into sub-process and stages in any way that suits their own needs. Powerful automation features will ensure every task has an assignee responsible for taking action to move the project forward.

As features are added to this new “Huly Project” type, the original “Classic Project” type with the existing lightweight version of the Action Item will continue to be available to users. For the foreseeable future, “Classic Project” will continue to be the default project type, so users won’t need to stress about onboarding their team to the platform with unfamiliar features.

Your support of our platform means the world to us at Huly, and we’d love to stay in touch on our Slack channel! You can also find us on GitHub and LinkedIn!

Stay tuned for further from the Huly & the Hardcore Engineering team to learn more about future developments.

It's funny how many people and teams, deep down, understand this at a very intuitive level but never raise the issue or even discuss it. And yet, the shared (incorrect) notion of source code as an asset prevails. This is a significant problem.

Let's start with the definition of an asset. According to Investopedia, an asset is a resource with economic value that an individual, corporation, or country owns or controls with the expectation that it will provide future benefits.

Source code is indeed a resource. So, what's the economic value of source code? It lies in the value of the software that can be developed from it. However, the software is not the source code. The software is the product that can be used to solve problems or provide value. The source code is merely a means to create the software.

Another common misunderstanding is that to build more features, faster, or better (whatever that means) software, you need more source code. This is a deeply flawed notion that is prevalent among engineers, managers, and business owners: more code equals more features. This is completely wrong. More code simply means more code and nothing else. Let me illustrate this point with a very simplistic example. I could write three lines of code adding three "features", and then I could write one line adding many more features, including those three:

const feature1_add5(x: number) => x + 5;
const feature2_add10(x: number) => x + 10;
const feature3_add25(x: number) => x + 25;

Or we could do it like this:

const better_add(x: number, y: number) => x + y;

You might think this is a silly example, and of course, everyone would choose the latter, but you're wrong. Almost every large codebase uses the first approach. I have never seen a codebase where 50%-90% of the source code could not be discarded, destroyed, and replaced with a small fraction of lines. This includes prominent open-source projects, Fortune 500 companies, and various startups, and it happens for many different reasons.

Why is more source code bad? Because source code is what ultimately kills you, kills projects, products, and companies. Complexity only increases, and you need to continue developing it, you need to maintain it, and you need more and more people to do that. More people means more communication, more coordination, more bugs, more problems. And more problems mean more time to solve them, more money to pay for that time, more stress, more frustration, more burnout.

Eventually, any codebase dies because of its source code. Some companies start calling it "legacy code" and attempt to rewrite it from scratch. This is a quite common scenario. Some companies do this every 3-5 years. And they never learn. They never learn that source code is not an asset -- it's poison. It's a poison that may kill a company, project, product. And then, after tossing out the "legacy" codebase, they start producing new poison very enthusiastically. It's ironic that the faster they produce it, the faster they meet their demise.

Of course, there are exceptions. There are very few people who understand this. Take the Linux Kernel as an example. This is a great example. But there is Linus Torvalds, who understands that source code is poison and works with it as everyone should. The only way to work with source code is the same way people work with dangerous chemicals.

You need to be very careful, very responsible, and very professional. Try to contribute to the Linux Kernel, and you will see how challenging it is. Attempt to contribute something, and you will quickly realize how sternly you will be rejected if you're not careful enough.

OK, that's the Linux Kernel, but I'm pretty sure your manager's name is not Linus. Your manager is the opposite. I believe they want you to contribute more code, any code, and perhaps will even reward you with achievements and bonuses for the number of lines you contribute. That's common, but also very ironic. People giving kudos to each other for making things worse, which ultimately leads to downfall. And they seem to want this to happen as quickly as possible.

And a few more words about poison. In small amounts, poison can serve as a great cure. Ancient medicine widely used poison to heal people. Poison is good in small amounts. But in large amounts, it kills. Source code is exactly the same. We can't ship products without source code. And in small amounts, source code is awesome. But large amounts of code are lethal.

OK, let's summarize:

• More code does not mean more features. In fact, it's the opposite; if you always aim to minimize the size of your codebase, you can end up with many more features implemented in a much smaller codebase.
• Source code is not an asset. It's a liability. It's poison. It's a dangerous chemical. It's a weapon of company destruction. You should avoid producing it as much as possible. If you can eliminate some code from your codebase right now, just do it.
• You should not be thankful to anyone who adds more code to your codebase, but you should be very thankful to anyone who removes code from your codebase. This is the only way to survive.

Working with AI now feels like coding alongside a really cool, productive, and smart partner who's always there. For example, I recently wanted to add Huffman coding to my toy project. The last time I worked with Huffman encoding was about 30 years ago, so without AI, I would've needed to spend some time looking things up on Wikipedia and other places. With Zed and GPT, I added Huffman encoding to my project literally in 5 minutes. You can see the result here on GitHub.

What does this mean? It changes everything. Imagine I'm a manager at a tech company, and I decide to add Huffman encoding to see the effects of compression in my library. Normally, it would take several meetings just to decide if we really need it and if we have the resources for it. Then, someone might be assigned to look into it, which also involves planning resources. This person would likely spend days evaluating different libraries. A week later, I might expect something to be done, maybe not. With AI, I had it working in my project literally in just 5 minutes. This is a huge deal.

But the impact is even bigger. AI is now better than 95% of software engineers in the world at many tasks. Take the Huffman example and try to compete with ChatGPT on implementing algorithms like that. This would be hard for many engineers and take much longer. If you disagree, just ask next candidate to write Huffman coding on coding interview and enjoy her suffering. Sure, GPT's output may require some tweaks, but overall, I'm achieving results 10 to 100 times faster than when working with humans, and often with superior quality.

Current hiring processes are outdated. If you're still making engineers do tasks like reversing linked lists or solve other Leetcode problems in interviews, you're missing the point. GPT-4 can do these tasks better. If you're asking about "system design" in interviews, you're even more behind. GPT-4 will probably give better answers than almost any engineer you could hire. This is a huge shift in the industry, and many people will start realizing this soon.

I do not want to say you should rely on ChatGPT's opinion on design of your system. Moreover you should not, and this is why real engineers are still needed and will be in more demand than before. But the point is that the hiring process is outdated and needs to be changed. You should not ask engineers to solve Leetcode problems or reverse linked lists in interviews. Why would you hire a mediocre coder when GPT-4 can do it in seconds for $50 a month?

I'm really happy with these changes. It's a big boost for the industry, but it's also going to change things a lot. Likely, 95% of software engineers (as most people think of the job) will be out of work soon. They're just not needed anymore, and they're falling short in the tasks they're currently doing. Industry should rethink software engineer role and focus them on what's really important. It's not about writing code anymore.

Think about how AI is changing software engineering like the tractor changed farming. Sure, we still have farmers, but they don't need to do the hard work in the fields themselves anymore. Their job has changed to managing the farm, making important decisions, and planning for what's coming. They don't need to rely on physical strength -- they need to be smart and know how to use the machines.

This is pretty much what's happening with software engineers now. They don't have to spend all day writing code. Their role is shifting towards project management, deciding what needs to be done, and preparing for the future. If your engineers are still spending days on something AI can do in a few minutes, it's like being that farmer who still uses a horse to plow the field. The world has moved on, and so should the role of the software engineer.

If you want to be productive, not only with coding tasks but also with everything related to teamwork, including collaboration and project management, you should try Huly. Huly aims to be the Zed of project management and team collaboration.

We're not quite there yet, and Huly's current process management capabilities are somewhat similar to what Linear, Asana, Jira, and others offer. However, we're passionately working on it.

Stay tuned, and you'll see how Huly will positively change the lives of many teams.