-1744950869.jpg)
Temelio is grants management software for foundations, the organisations that give money to nonprofits. A foundation uses it to take in proposals, review them, sign agreements, schedule payments and collect the reports grantees owe afterwards.
Maya Kuppermann (CEO) and Ruthwick Pathireddy (CTO) started Temelio in mid-2022, and since launch nearly all of its design had come from Jonah Allibone, their first engineering hire. By June 2024 the product had outgrown that. Enterprise foundations were buying something built for small ones, and a rebrand from the previous August had never reached the interface. They wanted a focused sprint, with the first two weeks as a trial either side could stop. We ran six weeks with the three of them, and Jonah built from our designs as we went.
A grant has a long life after the application
A foundation's work starts with choosing causes and finding nonprofits to support. A successful application then brings an agreement, payments and reports on how the money was spent. A grants manager needs to follow the whole relationship, while a reviewer may only need to read the proposal and give a decision.
On our first call, Maya explained that Temelio served small foundations as well as larger teams. Some people used it every day. Others came in occasionally, with very different levels of comfort with software. A redesign had to make a complicated process easier to follow without taking away the configuration foundations already relied on.
What I noticed on that call was that nobody does their whole job in Temelio. One grants manager lives in it every day, and everyone else drops in weekly to read an application or pull a report. Ruthwick put it plainly: people sit in Gmail or Slack all day, and they want to spend as little time as possible in Temelio so they can get back to the organisations they fund.
Build the shared components where the workflows already work
About 70% of the product needed standardising and about 30% needed rethinking, mostly in settings. I asked to spend the first week on screens nobody was attached to that still used a lot of components: Tasks, Payments, Grantee Reports and the CRM tables. Those screens gave us tables, menus and form controls that the harder sections would also need, without changing their workflows at the same time.
Colour was the visible problem. I asked what they wanted to look like (and asked them not to say Linear; Jonah said Attio), and the one firm answer was not grey and blue. Avoiding that had produced what Ruthwick called a rainbow explosion, which looked childish to the enterprise buyers now evaluating it. We cut the text styles to about five, built a smaller palette, and brought in the rebrand. Foundations tag proposals and grantees in sixteen colours of their choosing, so we kept all sixteen in softer shades, named apart from the interface colours.
The proposals page has to hold thirty stages
Some clients run thirty stages from draft to awarded, and Maya had already watched a card layout compress until the labels wrapped. I considered having the dashboard’s stage counts deep-link into filtered proposal tables. Ruthwick showed why that could fail: foundations can delete a table, change its filters or create several views of the same stage. A count for “In Review” could not reliably link to one of those views. We needed to preserve the custom tables while giving people a dependable way to browse the stages. So Proposals got a page of its own: stages down a sidebar, each with its count, and the proposal tables beside them. That kept the stage names readable as the list grew, rather than asking thirty labels to fit across the top of the page.
The main navigation had the same problem in miniature. We mocked up a few hierarchies, and no fixed ordering suited every foundation. Jonah suggested letting people star the pages they use and pinning them to the top. The pages a person used most could sit above the shared navigation.
Give the dashboard limits people can work within
The dashboard was the first page Temelio built in the new design. Before we drew it I asked whether a customisable one was worth building at all, because it's an easy thing to overbuild. We limited card widths to half or full, rather than allowing arbitrary resizing. Foundations could arrange proposals, tasks, upcoming payments and budget categories, while we could design a known set of layouts for each card. Proposals still needed to work at half width, even when that meant changing its stage selector. By the last review Jonah had built it without the edit mode I'd designed, with drag handles appearing on hover. We dropped the separate edit mode and kept his approach.
half or full width keeps card layouts predictable
Pipelines are drawn as the branching flows they are
The biggest rethink was pipeline configuration, where a foundation sets up the stages its grants move through, each with its tasks, emails and automations. Temelio showed every pipeline on one page, as a straight line. A real process can branch, including paths that end in rejection. A straight sequence did not explain which conditions sent an application down each path. When Ruthwick raised a builder I had a rough one to show, not even React Flow, just divs on a dotted background. The question I kept putting back was how much of a breadboard it should be: what goes on the canvas, and what stays in settings.
Each pipeline got its own page, drawn as a flow, with stages as cards and triggers between them where the conditions live. In the review we agreed to show task names on the cards. A task's name goes straight into the grantee's email, so foundations write them out in full ("Upload Signed Grant Agreements").
New pipelines start from a template of Temelio's standard stages, and stage labels are suggested in order, so the stages the rest of the product depends on are always there. Ruthwick also showed how adding a task used to mean leaving the pipeline, building a template elsewhere and coming back to select it. We designed task templates and emails to open in trays over the canvas. Someone configuring a stage could create the work it needed without losing the process they were editing.
build tasks without leaving pipeline setup
Find the record without knowing which section owns it
A search might return a task, a proposal, a grantee or a document. We added category tags so people could narrow the results without retyping the query. The four buttons crowding the data filters went into one menu, and empty states got a single next step.
narrow the results without retyping the search
Keep the organisation, its people and its grants connected
"Donor management" had sat on my questions list since the first week, and at the last review I admitted I still didn't know what we were managing. It meant a full CRM, with organisations, people and vendors linked to one another. The contact pages needed to make those relationships explicit. A grantee’s page brings its grant history, funding and team contacts together; a constituent’s page connects contributions and custom properties with the organisations they relate to. We designed the contact pages and inbox around those different records.
Handing it over
After the last review we reorganised the Figma file into a page per feature, so Temelio's team could keep working in it. Jonah was already implementing the new dashboard, and the handoff included the component and colour system the rest of the product would use.
In July 2025 Temelio raised a $7M Series A led by Avenue Growth Partners, and Maya was named to the Forbes 30 Under 30 social impact list for 2025.
"The NBS team were amazingly collaborative, quick, and thorough. I would absolutely recommend them to anyone looking for product design at any level!"
More from Temelio
