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. This blog post is a follow-up from the post last year, “How We’re Working, 2024”.

We are hiring at the moment, which is part of what motivated me to update this blog post. You can see our open roles on our About page.

I’ve left parts of the original blog post inline, but block-quoted them. Anything unquoted is new. Hopefully this gives a nice pseudo-diff view of what’s changed over time. For example:

Here’s what we did last year, and still do this year.

Here’s something new this year.

The company

We’re a young company of 12 at the moment. 4 engineers, 3 folks on ops, our sales team, myself (CTO), and Rusty, our CEO. Our day-to-day can look different every day, it really comes down to what the biggest priority is for the business at the moment. We are located in Denver and Seattle, with our sales folks spread throughout North America.

We’re continuing to grow the company in Denver and Seattle.

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 continue to collect customers, and we’re starting to see customers trust us with larger parts of the faculty lifecycle. In the last 12 months, we saw our first major public institution and our first law school sign.

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.

We’re starting to see the tailwinds of this trust that we’ve built up, with all of our customers going to bat as references!

It’s hard to overstate how detrimental the newest political administration has been for our customers. The freezing of NIH and NSF funds caused us to wonder if we’d even survive. Scholarly resonates with research-heavy, data-driven organizations. The NIH/NSF funding freezes and cuts affected those institutions.

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 specialized workflows. These workflows might be annual performance reviews, leave or sabbatical processes, or hiring processes.

In the last year, we’ve poured a lot of investment into our workflow engine. It’s now self-service and more capable. What used to require engineers writing code for each workflow can now be configured through our UI or, better yet, our AI. This AI-powered workflow setup saves administrators weeks of time.

Our product is a SaaS application written in Ruby on Rails and hosted on Heroku. We use PlanetScale for our database and still use as little JavaScript as we can. Due to customer volume, we recently had to add not just a web dyno but a Sidekiq dyno too!

We invested in the last year in building our own design system and component library, but still make use of Tailwind and TailwindUI where necessary.

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.

We’ve also invested heavily in our reporting capabilities, AI Assistant, and other parts of the product in the last year. Our newly-minted blog recaps product improvements we ship every month.

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.

This was how we worked last year, and it’s still largely how we work this year. However, this year we’re putting more effort into systems to scale our efforts internally.

We’ve switched to Linear for project management and had a brief pit stop using Basecamp. Linear’s a great application and is serving us well. We use the “Cycles” feature extensively, planning out what work we plan to do that week.

For customer-facing project management and communication, we’ve transitioned our customers to Slack. Many institutions use Slack and we’ve found the quick messaging invaluable for keeping project velocity high, especially during implementation.

Since last year, our customer management has gotten more hands-on as our team has grown. Our operations team manages the relationship with customers, and is keeping a much closer eye on implementations than Rusty and I can.

Project management still follows a simple kanban approach, but the tickets have accumulated a lot more tags these days. We work off of the topmost tickets, deciding the rough ordering at the beginning of the week. All members of the team are welcome to add things to the top of the board as they find bugs, potential improvements, etc. We try to represent all work as tickets, but don’t always succeed.

We’re leaning more into feature flags and some other tools for making it easy to test in production without harming the customer experience or corrupting customer data.

The ethos

Where we had originally started integrating every data source “by hand,” we’ve started to build systems around common integrations that we’ve seen. We did things that didn’t scale and now are reaping the rewards.

We’ve got a growing API that more customers are tapping into. We have some solid rails for working with common systems found in higher ed. We’ve put together APIs that are compatible with competitors’ systems to make switching easier on university IT teams.

We’re finding the balance of how involved engineering should be in implementation. We’re building more and more tools that our operations team will crank on and inevitably break.

Our goal is still to put many of the powerful tools in front of customers so that they can self-serve the configuration and operation of the platform. For many of the most powerful pieces of the application, these are still ops-only tools.

It’s still important for everyone in the company to deeply understand the customer pains. We also ask everyone to understand the business bottlenecks, since the best ideas can come from anywhere. We ask everyone to stay plugged in because it helps us learn, and then bake those learnings into the product.

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.

(Checking in on the above sentiment a year later, this has started a deluge of switchers off of our competitors. No surprise.)

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.

The tools have changed, but the ethos has not. We’re still plugged into the customers’ needs and everyone knows our stakeholders by first name.

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.