Paragon Enables Low-Code Software Development For All

Some would argue because of the need of software in nearly every business today, more companies are having to become tech companies. However, the expertise needed to build software internally within a corporation is expensive to acquire. Also, not everyone has the skills to program proficiently. Ishmael Samuel and Brandon Foo experienced first hand challenges of build good software, as it was expensive and time consuming. The two created Paragon to solve that problem for others. Paragon is a software startup providing users’ with a visual workflow and API builder. The Los Angeles-based startup was recently a part of Y Combinator’s Winter 2020 batch.

Frederick Daso: In our previous conversations, you’ve asserted that every new company being built today is a software company, even if its goods or services aren’t software themselves. Could you explain this concept in more detail, and tie-in how Paragon fits into this narrative?

Ishmael Samuel: Sure. Our thesis behind creating Paragon is that every company needs software to exist in today’s world. This extends to just about every process in the business from communicating internally and externally (text messaging, emails, notifications), finance and accounting (invoicing, payment processing, reporting), marketing, operations, etc.

What we’ve done at Paragon is to allow companies to visually build simple and complex APIs and workflows that integrate with both internal and external tools. Technical and non-technical users can quickly connect their databases, spreadsheets, payment processors, marketing tools and more to build product features or automate operational processes in minutes without having to set up or manage technical infrastructure. This allows them to develop quickly, learn and iterate, and focus on their core value propositions.

Daso: The idea that even with the abundance of software and its derivative tools, it is still hard and time-consuming to build great functioning code, which is counterintuitive. How did you understand the core problems stemming from this unresolved paradox?

Samuel: Brandon and I previously founded CTRL LA together, a software development agency based in Los Angeles. After building many of the same things over and over again, we started building internal tooling that allowed us to quickly set up common features like authentication, notifications, and payment processing, but managing these common components and integrating them into each product was still cumbersome.

We came to realize that a good chunk of time spent building software was either building common components, reading or writing information to data stores, or writing code integrating with 3rd party services. More so, we believed that the most valuable work that was unique to each business was the information that was sent between the various components and the linear workflows that defined them.

Many of the 3rd party software tools that companies use today expose an API or SDK that can be used to interact with the underlying data specific to their company. Tens of thousands of APIs currently exist, and thousands are being created every year. Unfortunately, writing software on top of them still requires a lot of technical expertise. We believed if defined visually and in the context of the other services that need them, anyone could use them.

Daso: How did you identify your initial set of customers to work with?

Samuel: While we had a strong thesis and first-hand experience with the problem, we needed to make sure other people also experienced the same adversities. We reached out to founders at startups and agencies and conducted back-to-back user interviews for weeks to learn about their development processes, tools that they used, and their greatest pains. It was important to understand their existing processes before introducing new ones.

We created mockups for a product, presented them to these potential customers after interviewing them and listened to their feedback. We iterated on our initial thesis and MVP until the pushback and “nos” started turning into, “Sign me up – I’m ready to pay for this.” Once the feedback was predominantly positive and from what we believed to be the right segment of users, we started building the product and hiring the team. When we were ready to launch, we had a list of qualified users ready to pay and use the product in our private beta.

One key learning here to be shared is that the product we have today is not the product we had in mind when we initially started. During those interviews, we got a lot of pushback because we had planned on hosting the users’ backends, storing all of their data, and more. This also presented issues with our go-to-market strategy because we had a small window in which users could get on Paragon, i.e., the beginning of their product lifecycle. This initially prevented later stage companies from using Paragon unless they were building a new product that didn’t yet have servers, a database, etc.

Our thesis wasn’t just the problem that we had discovered but the solution that we were bringing to the market. Testing all parts of our hypothesis was monumental in creating what Paragon is today.

Daso: What did you learn from them that gives you greater insight into the growing market for rapid app development?

Samuel: We found many of our users spent the first week or two of their project development lifecycle just setting up a project, meaning servers and infrastructure, databases, boilerplate code, utility libraries and more. For production applications, there’d be even more time spent setting up sandbox and production environments, logging and analytics, and other standard functionality that’s required for testing and visibility. For teams, access control, version control and security were also crucial for collaboration.

Advanced developers needed the ability to eject or write custom code in the situations that the user-interface provided didn’t meet their needs. Generally speaking, everyone was concerned about scalability and performance, but few had the expertise in building systems that could handle large loads while still being cheap at small loads. The most critical consideration in technologies was speed to implement and iterate.

With that in mind, we set out to build a platform that would reduce the time and expertise required to build production applications from weeks to minutes, deploy instantly with visibility in production, and scale from zero to infinity without needing to worry about the underlying infrastructure. Furthermore, we required collaboration abilities and to ensure that advanced developers had the flexibility to write their custom code for advanced use cases while providing simplicity for non-technical users.

Daso: What are the advantages of a visual workflow versus a traditional GUI for creating code?

Samuel: When building a workflow or API in the standard way, users need at minimum access to a code editor, terminal, and the programming languages installed on their machine. From there, developers need to compare many libraries for integrations, dig through the documentation for the necessary functions, browse forums to troubleshoot common integration problems, start and stop servers while monitoring console logs, and more.

This prevents at least 99.9% of the population from being able to do even simple tasks. And for the remaining technical users, this might still take the better part of an afternoon for many everyday things. If one wants that code to run on a remote server or a schedule, the complexity only multiplies from there.

With a visual workflow builder, the underlying libraries and implementations are abstracted away. Users can focus entirely on their application logic, like what should happen, when it should happen, what filters to use, etc. as opposed to the low-level minutia like server resources, dependency management, or security.

Daso: How does your startup’s API builder simplify the process of allowing applications to communicate with one another?

Samuel: Paragon’s visual workflow builder allows people to connect their 3rd party applications in seconds. We provide provider-specific methods for each integration’s functionality, like searching, deleting or updating data, sending text messages and emails, and more.

Each step has an input and an output. Steps’ input can be mapped from previous steps’ output, and a steps’ input can be combined from multiple upstream steps. This allows users to build complex workflows in minutes that integrate multiple services. An example of a common workflow is “Every morning at 9 a.m. PST, connect to this database. Find all the users that haven’t been active in the last 30 days, send them an email with this service, wait one day, then send our team a message in Slack to reach out to them manually if they still haven’t logged on.”

We provide a visual workflow builder with building blocks for triggers (scheduled jobs and HTTP endpoints), integrations with popular services, and routing logic. Thus, we’ve created a platform that allows anyone to build sophisticated software in minutes that previously took months of expensive software development time and expertise. Each workflow or step can be tested and iterated upon with logging and step-by-step debugging capabilities provided out of the box in test mode and production. The credentials are stored with bank-level encryption and execute in milliseconds.

It’s so intuitive and straightforward to use that we’ve found it’s more productive to use Paragon for many of our processes. We built our billing & payment processing, uptime notifications and user signup flows on Paragon and are moving more of our internal processes to it every week.

Daso: You’ve stressed in prior conversations at length about your process for finding a cofounder. What was that like searching for one, and how has your decision to partner with Brandon Foo turned out?

Samuel: Honestly, I believe that who you pick for your cofounder is the single most crucial decision you can make throughout an entire company’s lifespan. More so, consider that you’ll likely be working with this person 10+ hours a day for at least the next few years, and the financial outcome of the business will affect every other aspect of your life. I believe it’s the most important decision I’ll likely make in my 20s. In a lot of ways, it’s like marriage.

Consequently, I spent a lot of time thinking about what makes my ideal cofounder. I asked myself, “Who can I work with for the next ten years, and what factors would they need to have for that to happen?” The things that mattered to me most were trust, temperament, values, and ambitions.

Trust comprises of both integrity and ability. It’s essential that you can trust your cofounder to have both the ability to execute what’s needed of them and the virtue to do so with tact and integrity. They should be able to represent themselves, yourself, and the company professionally. Having someone that’s honest but bad at what they do or great at what they do but dishonest will lead to nothing but trouble.

Temperament encompasses self-awareness, rationality, temper, and sociability. It was important to me to find someone who could recognize their deficiencies, be willing to discuss them and improve them. Keen awareness of self also prevents one from easily being swayed by less self-realized individuals that act from ego. I’m also generally a very positive and high-functioning person and need someone with a similar disposition, lest it corrupts my own. Sociability is vital in fostering a healthy culture and friendship. In summary, I needed someone confident, friendly, and rational.

Values go deeper than interests and are a foundation for a good relationship. You can gauge values by watching how one discusses others when they’re not around, understanding their world views and seeing what they do in their free time. While you don’t have to have the same interests, having the same values ensures long-term cultural alignment.

Ambition is obviously essential when trying to build a billion-dollar company. In measuring drive, I wanted someone who wanted to change the world and build the best version of themselves while doing so. The question I used to measure ambition was, “Who is going to succeed whether I work with them or not, and what will they be successful in?”

I’ve had an ongoing list of interesting people I’ve come across or worked with. Over the years, I’ve paid attention to what they’ve said about others, how they’ve improved themselves, what they’ve accomplished, and more. Brandon was at the top of this list. We’d been friends for years, and had a previous successful working relationship. I had been subscribed to his investor updates email newsletter at his last company, Polymail, which was a very successful startup and a beautiful product all around. When I heard he left the company, I immediately reached out to him for lunch and told him I wanted to work with him. I shared with him a list of maybe 50 business ideas I had and another 100 hundred companies that I had done some research on that had been successful.

My thinking was that with the right person, we could work on anything and have a good shot at creating a world-changing company. It was more important to me who I worked with than what we worked on, and I believed Brandon was someone I could work with for the next decade, even if the company changed. It’s been about a year since that lunch, and since then, we’ve built an incredible product backed by some of the world’s most prestigious investors, raving customers, and an incredible team. All in all, I’d have to say it’s probably the single best decision I’ve made in the last few years.

source: forbes