This blog post goes into detail on how our company, Scholarly, works. This post should serve as a bit of a memory capsule and a good thing to send potential candidates when they are evaluating us.

I hope this blog post is an interesting view into what building B2B SaaS can look like in a way that is traditionally agile: personalized, great software built in cooperation with our customers. No focus on frameworks, tools, or processes.

We’re not hiring at the moment but hope to be soon.

The company

We’re a young company of 4 at the moment. 2 engineers, myself (CTO), and Rusty our CEO. Rusty handles the sales, the rest of us handle building stuff. We are located in Denver and the Pacific Northwest, with a small office space in Seattle.

We hope to grow the company in Denver and Seattle, but are open and familiar with remote.

We have been in business since June, 2023.

The customers

We sell to universities within the US.

There’s a very specific set of individuals that we sell to within a university. No HRIS or competitor serves them well at the moment. They are really underserved but serve one of the most crucial functions of a modern university.

We are lucky enough to have collected quite a few customers in our first year, many of them name brands that we’re not quite ready to talk about yet.

Universities put a premium on what we do, so we are definitely into the “enterprise-level” ticket prices of B2B SaaS products even with our nascent feature set. Much of what our customers buy is the relationship with us, putting their trust in our ability to continue to develop and deliver a valuable product for them.

The product

Our app provides a source of truth for departments, colleges, and universities that makes it easier to manage faculty. Management of faculty centers around specializes workflows. These workflows might be annual performance reviews, leave or sabbatical processes, or hiring processes.

Our product is a SaaS application written in Ruby on Rails and hosted on Heroku. We use PlanetScale for our database and use as little JavaScript as we can. We use Tailwind and TailwindUI.

We deploy every time the build goes green, automatically.

Every university is different, so the technical depth of the application comes from the sophistication and flexibility of our data model. We adapt to every customer’s data without compromising the integrity required to build sophisticated reports and consistent workflows.

The process

Every piece of work we do begins with the customer. We source problems, come up with solutions, show them a prototype or a riff, put some polish on it, make sure it meets their needs, and then check in a few weeks later to make sure it’s still meeting their needs. We spend a lot of time talking to customers.

Our entire product and engineering process mostly operates out of a single Trello board. Tickets range in size from copy fixes to meaty features.

For customers that use Slack, we set up shared channels between our organizations.

At the end of each week, we try to record videos for our customers of what’s improved in their account that week. We also use those videos to higlight idiosyncrasies or things we’ll want to discuss the next time we get together.

Our app has an ever-present “Submit Feedback” button which customers can use to send us notes about the app. Those notes get dropped in our main Slack channel for all to see.

When meeting with a customer, we pop open our Trello board. Each card has a tag for the customer. We filter down to just their cards and go through the list. We make sure the list of work to do is comprehensive. From there, we ensure that the list is ordered in a way that is most valuable to them. The most important stuff goes at the top. When picking up new work, we pull from the top of the list.

This simple kan ban approach has been a remarkable learning so far. We try to interleave different customers’ tickets so that everyone gets a little bit of progress. We pull up the ones that will hit multiple customers or are required for a customer-defined deadline (e.g. “Our performance review process kicks off March 1, so we really need this feature by then!”) Rather than promising big bang feature sets, we’ve created a relationship where the throughput of value remains constant. They can and have changed prioritization week-to-week, and we’re right there with them to roll with the punches.

The ethos

Since we are young, we are consciously doing everything “by hand.” We integrate with a lot of different systems like Workday and other HRIS’s. We will pull data from Excel, CSV, or scanned-in documents dating back to before anyone in the company was born.

We always work with this data by hand to start, pulling it into our application. This gives us a better sense of the shape of the data as well as exercise our own application.

Once we feel we’ve learned enough, we’ll start to build internal tools to solve for the bottlenecks. This usually has to do with implementing a new customer, where we might be pulling in tens of thousands of records spanning decades.

Eventually, we put these tools in front of customers so that they may self-serve and drive their own accounts. It’s amazing how much of the app just has the “R” in a CRUD interface and that’s okay; some things only change once during onboarding. Over time, we fill out the C, U, and D as necessary.

We do things in this order because it helps us learn, and then bake those learnings into the product. None of us come from a background in higher ed (other than attending), so learning is an incredibly important part of our product development process.

The results

We’re having a lot of fun, and so are our customers. We get to work together to build software that solves very real problems of theirs. They like paying us.

They are willing to recommend us to other institutions and peers out there, which really greases the wheels of the next sales conversation.

The reflection

Our ability to ship something minutes after a customer requests it gives us a competitive edge.

At the competition, customers are encouraged to pay an additional fee on their contract to hire an “internal champion” to advocate internally for their feature requests. These features never get built (surprise). The incentives are so perverse in this setup, we couldn’t believe our ears when we first heard it. Folks using the competition go months without communication, and many have been waiting years for bugs to get fixed or product improvements to land.

We’re in a space where we’ve got great alignment between the problems, our technologies, and our skill sets. It’s an opportunity-rich environment.

What’s next?

Change, obviously. This is how we’re working now, but it may not be how we work in the future. How long can we really operate out of a single Trello board? How scalable is recording a video for each customer every week? Time will tell.

If we continue to see success, hopefully we can look back on this post and still see some of the values and principles shining through although the applications might be different. Most of all, I hope we’re still having fun.

Until next year or so.