Podio Solutions Podcast

S1E3 - How We Built mPact Pro - Development (Part 2)

February 01, 2019 Brick Bridge Consulting Season 1 Episode 3
Podio Solutions Podcast
S1E3 - How We Built mPact Pro - Development (Part 2)
Chapters
Podio Solutions Podcast
S1E3 - How We Built mPact Pro - Development (Part 2)
Feb 01, 2019 Season 1 Episode 3
Brick Bridge Consulting

Season 1 – Episode 3 – How we built mPact Pro: Developing Wide-Scale (Part 2 of 3)

 

Discussion Outline:

  1. Introduction – Welcome to Part 2 of 3 -- How we proceeded into Beta and the technical side of building a wide-scale Podio solution.
  2. Topic: What were the steps to building a Beta in 14 months? How was that experience?
  3. 1st Discussion: Consulting & Development
  4. Hot Topic: Why was software like Globiflow, Zapier, etc not able to fit the use cases needed?
  5. 2nd Discussion: SaaSsafras Service Design
  6. Real Talk: Limitations – What was the limitation of Podio's API that impacted the design?
  7. Deep Dive: Controlling the Development Process – Why is the “Discovery” portion so critical in Podio development?
  8. Up Next: mPact Pro – Diving into CVP and the "business" side of this 3 part series.
  9. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  10. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.


Support the show (http://www.brickbridgeconsulting.com/podcast)

Show Notes Transcript

Season 1 – Episode 3 – How we built mPact Pro: Developing Wide-Scale (Part 2 of 3)

 

Discussion Outline:

  1. Introduction – Welcome to Part 2 of 3 -- How we proceeded into Beta and the technical side of building a wide-scale Podio solution.
  2. Topic: What were the steps to building a Beta in 14 months? How was that experience?
  3. 1st Discussion: Consulting & Development
  4. Hot Topic: Why was software like Globiflow, Zapier, etc not able to fit the use cases needed?
  5. 2nd Discussion: SaaSsafras Service Design
  6. Real Talk: Limitations – What was the limitation of Podio's API that impacted the design?
  7. Deep Dive: Controlling the Development Process – Why is the “Discovery” portion so critical in Podio development?
  8. Up Next: mPact Pro – Diving into CVP and the "business" side of this 3 part series.
  9. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  10. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.


Support the show (http://www.brickbridgeconsulting.com/podcast)

Gil Roberts:

Welcome to the Podio Solutions Podcast. Episode 3 Season 1. I'm Gil Roberts with me today is our lead developer, here at Brick Bridge Alex Shull.

Alex Shull:

Hello

Gil Roberts:

It will just be Alex today joining us. Jarett will be back on the next episode. This podcast is about the design and development on the Citrix podio platform. podio.com P O D I O.com. Now we're going to be using this podcast and discuss your own experiences with podio as well as the experiences of others and interesting topics from the podio developer community. Um , both in the forms and with your participation. If you are a podio designer, developer working at an agency, small business, or even in a large enterprise, then you should immediately a crush on that subscribe button if you haven't already. So thank you so much for your support. Lastly, before we dive into today's topic, if you have a topic, issues, solution, problem, anything that you would like us to discuss or look at, please, we want to talk to you , reach out to us on Facebook, linkedin, Twitter, or send an email or a podio message to podcast @ brick bridge. And again, please subscribe. It helps us out more than you know. Uh, today's topic is part two of our, how we build impact pro. Today we're gonna dive into the development side. So we're going to get a little nerdy here and , and talk about the API Apis and some of them are the technical aspects when working with a wide scale solution on the podio platform. Again, with me today is Alex Shull. Uh, we're, we're just gonna dive right in as we usually do. Uh , this will be part two of three. So I have a third one in the third part. We're going to go over more to the business side, but we'll let that sit until next week. Uh , first and foremost for this episode, we're going to cover how we proceeded into Beta and then as I mentioned before, the , the technical side. So , uh, Alex , I'm gonna just start you out with our kind of main topic here is , uh , what, what were these kind of initial steps when we brought you on board because you came on right away later in the process. And , uh, you know, we, we took what about 14 months roughly of this side? So this was definitely a lot longer than the 90 day Alpha that we discussed last. But , uh , so kinda tell me about that, how , how you got started and the experience so far.

Alex Shull:

Yeah. Um, well it's , uh , looking back it seems like forever ago now, but , um, the, what do you and your first approached me about the opportunity to work with brick bridge. Um, you had already been working successfully with podio for quite awhile and I had worked with you a little bit prior on podio solution , um, prior , um , business mentioned we have , but , um, and it changed a lot since then. And , um, so it was kind of a reintroduction and when you brought it to me, the way you were using it was, was really interesting because it's a , um, it's a rapid application development platforms. What it is, it's a, it's software as a service, but under the hood it's a rapid application development platform and you can, you all, we're putting together a fully capable system for a client that wanted to deliver that solution to their customers. So this was your client , um, has already distributing some software. Um, and they were , um , savvy in the industry and they had already , um , set of customers. And so the, the challenges that you presented to me at the time and that I spent the next 14 months really unpacking , um, had to deal with taking the natural , um, result of prototyping a solution on podio and globiflow and taking it to that next level to where a client like this can distribute it as a vended software solution and can also , um , administrative the deployed , um, instances and provide updates to the clients. Um , all in a very smooth experience. That approach is software as a service for their customers. And so in a confusing way, the software is a service platform, which is podio, which delivers a rapid application development platform, required additional work to take that rapidly develop applications and deliver it as a software, as a solution service . And the key points that we , I really had to address in making this possible were the deployment of patching of the environments of the podio applications, the individual ones. And we had to build our own event engine to handle all of the interactions with those applications that , um , is significantly different than the approach that globiflow provides you for an example.

Gil Roberts:

Yeah. So a little bit going back to a point , almost like a little inception right there . Like a sass inside of the sass. Yeah. So we kind of saw inklings of that when we initially got the project together. And uh , for our listeners a little background and Jared and I, we are not software developers. Jared is a really great mind for software design, but from a technical standpoint, we , we , we have some experience in it. Mine is back in 2001. So that, you know, you'd have to get an archeologist that came on my knowledge back out . It's basically worthless at this point. But you know, we had an understanding of how software was made and kind of the intent behind design and user experience. But uh , that's why we brought you on because , uh , your background in software architecture and enterprise. Um, so we , we saw the, the ability for this to be there while we just did not understand, especially at that time cause I think that was , uh , roughly May or June of 2017 we didn't have a full vision into what it could and could not do.

Alex Shull:

Yeah. And I didn't understand all of the , um, the constraints that we would face either. Um, and it's been a, a learning process going forward. But , um, I have been , um , impressed with a lot of the good decisions that the podio team made in the design of their API that enabled them to really preserve that functionality. And if one of the thing that you want, if you're building something on top of an Api, you don't really want the API to change unless it really has to and you really want, if it does change, you want it to be backwards compatible if it can be. And so , um, they have done a good job of designing an API, separating their concerns and making sure that the way to construct an application on podio does not bind you into one way of building applications. And so that, that, that made me realize that there was , um, a good potential to, to manage the application the way we need to do.

Gil Roberts:

We, we saw that a little bit on the surface. I think that's what kind of drawed us in as nontechnical side, which was how easy it was to design applications and rapid application platforms as you describe it. Uh , and then how flexible they were around, that we weren't getting fenced in into a certain type of usage. I mean, podio is when , when I first encountered it in 2012, late 2012, you know, it was really built as a CRM project management. But we saw that and when we started using it then , uh, we just saw for so much more that was kind of this up of social media and , and database and workflow software, which just kept us engaged and curious over the years, which led us to, to impact pro in the opportunity that, that

Alex Shull:

I've seen it described as group where , which I don't, I think there's really an accurate, and I think it's a little bit of a puzzle because it doesn't fit cleanly into some of the other boxes that I've seen for , um, you know, the kind of sass solutions that are available. But , um, but yeah, the, the, I think that one of the , the real marks of the podio platform is that you having the Api be really fully capable Api . You can drive everything except for the Ui itself using the API. And that's what makes it such a flexible platform, integrate with,

Gil Roberts:

well, I know we've had some frustrations as we've gone through bill rice , most large projects have, and then some of the turmoil and then some of the wins and successes , uh , that are available. Um , what's, what's Kinda jump into kind of our first discussion, which is that the consulting side and, and how it fit with development. Uh , your piece of the console . I know Jared and I talked about our piece last week. So just Kinda , how did you get that? And that would be I guess fall of 17 yeah . Roughly early, late summer. Early fall.

Alex Shull:

Yeah. Well there were, there were two aspects of, of my engagement in this project and one was as the Sass for us of developer as we started building our own platform, we would extend those capabilities of podio. And the other part was working on the impact pro solution. And My , um, involvement came , um, in figuring out the best way to integrate our solution with an external API. So we have to call me back. Pro has to submit data to housing and Urban Development Department, which is a government agency and the high API head . And um, their API is , um , XML over http and it requires , um, um , NTLM authentication. So you have to figure out those kinds of requirements. And I don't want to get into those details, but it's essentially

Gil Roberts:

soap service that we've talked about.

Alex Shull:

Yes it is and the, the, the essence of it is that , um, there's no good way to integrate that directly with podio. And there shouldn't be, that's not a concern that podio should be covering in their design. And you can go to a solution like Integra Matt , for instance, and you can do a lot of integrations through their services. But this is a very specialized case where because of the security requirements and because of the specialized nature of the service , um, signature, it's not something that is going to be available and Tagamet automatically out of to build a custom integration. And so at that rate, we built the integration on our backend and our custom Sassafras engine. And so we figured out a good way to supply a third party integration and give the user an experience of what is going on there through the podio interface. And so, that was our approach to provide a dedicated application for letting the, the user of the application see the results of the event of performing that integration. Um , in this case it's a business significant integration that the users have to be aware of anyway.

Gil Roberts:

And it just turned into a kind of round out. What they see is , is basically , uh , the housing counseling industry uses it and came back row that the software that we create for our client , um , and they can, they got to track their activities, kind of like a turbo tax or something like that. They have to report it up to the federal level at certain intervals. This allows them to do all the tracking in podio just, just as a normal podio system does just their workflow management . It's, it's very impact pro is very much like ACRM where it's just case management or stuff .

Alex Shull:

Yeah, it is. It's clients. It's um , cases is services, service. No, nothing. Case management's a good way to describe it.

Gil Roberts:

Yeah. Case Management , uh, some , nothing crazy, but what the government's involved or either federal comments at all . So of course we're going to have a little layer of complication in there . And then the service that they were talking about allows them to just do their work and then a manager can push some buttons inside of the interface and then submit. That electric report

Alex Shull:

Just to elaborate a little bit on, on how we develop that. When Jared was in on the process early, we knew their hood integration was a critical aspect of this application and we knew that providing them , um, a view into our competencies, delivering that quickly would actually go a long way towards building the relationship. Because when you're working in government things, especially speed is not what people are used to. And so we really wanted to show what we were capable of using the tools that we've chosen. If nothing else, podio is very impressive for delivering results quickly. So when we went into a, Jared already knew the requirements. He had already designed the application at the very outset, even before the Beta arrive to capture all the information we needed. He knew every single data element we needed. He had it structured to where all the relationships between the data are correct. Podio is a whiz at doing that. You produced that if you know your data, it's done in a day. It's beautiful. And so the layer that I'm talking about pulls those records out of podio transforms them into a custom XML and then submits them under the agencies , um , configured profile for that integration. And so it's just a , a reusable way of providing this third party integration.

Gil Roberts:

And what's amazing is that all that process from an end user standpoint, it's still control through the podio interface.

Alex Shull:

Yeah. We didn't need to build the UI. We were able to really handle the , the core interactions through the existing podio Ui. And there , there are a lot of cases where I would say that, yes, you should go out and build your own Ui, but we're finding more and more that we can really address the needs of our customers , um, to a very large extent before that need arises. Then it makes us more efficient. It makes us more cost effective

Gil Roberts:

and that that then, yeah, but definitely more cost effective cause mate kind of podio first and in our solutions and then maybe full on custom second option. You know , we're allowed to rapidly develop tests, get out in front of customers, get out in front of the area and end users, get the feedback, change the interface. Because let's face it, for the end users, they don't see all this fun stuff that we're talking about right now. You know, they just see the podium and they go to podio.com what is there is what the , is what they see and that impression and usage is so critical , um, to them. And it's great to where we have to get that out. As you said, even if we had a lot of the design out before we even got into the Beta and it was just so we're able to kind of get a couple of steps ahead. Um, something I want to talk about. I want to be labor , the Hud polling . I think that's a great highlight of this project. There's a few other third party integrations, a selling that we can disclose some that we can not cause they're not publicly marketed yet. So we'll, we'll leave some of those rest. Um, I think what I want to dig into now is, is the tools that we used to make Sassafras and our custom engine, which drives a lot of this third party and then into the actual actions, kind of why we had to, it's not like we disliked globiflow, but why we had to move.

Alex Shull:

No, no we love globiflow and then the, and I think that we , we use globiflow, um , maybe a little differently than some others. Um, use it. But , um , globiflow for us is a fantastic , um, prototyping tool. Um, and for a lot of our clients, they stay on globiflow because it completely meets their needs.

Gil Roberts:

That's true.

Alex Shull:

Yeah. And so we, we, we, we love globiflow we go in there. And if we need to build a proof of concept, we can throw that together and we , we don't have to deal with, with anything. But podio and globiflow um , vast majority of the time,

Gil Roberts:

a lot of times , uh , to that point a lot of times , um, just just showing somebody presale, we're working through the statement of work and you're trying to bring them on as a client, get the retainer check, you know , um , just having a few little things. When you click a button it does, it sends a message or something like that. So that's so easy to use, Globiflow.

Alex Shull:

Yeah. Do people want to see more than just a spreadsheet with data going into it? They want to know that when they're clicking buttons, there's some logic on the backend that understands their needs and saves them time by having things happen. And so the exactly flow we flow gives you that very first layer of integration and automation that you really need and go on. Sorry.

Gil Roberts:

Oh No, no. I wanted to add , I think this is great. It's a great point of value for our listeners to have one really great appropriate use for below . We flow and improve . The concept phase is to get with what we do is get like the top three or five business rules around what they're looking to automate and just, even if it's kind of a vapor of a vague awareness when I want to like throw out, but even if it's kind of that going on in the back or it's real thin, it just moves things around and makes it look like it's running.

Alex Shull:

Yeah. But this is part of the lean approach anyway. You want it , you want to get working things in front, in the user's hands quickly. And even if they don't look the final version that they'll look and things like that, that's not what's important. The important is to get the user using it and interacting with an experiencing it. And we can do that very rapidly using just podio and globiflow.

Gil Roberts:

A lot of our , and even more so because a lot of the people that were showing these proof of concepts to , or not a technical people, right? They're the , they're the business side. They're the ones that have a management layer that, you know , you start talking Api Apis with them . They just kind of, yeah, to clock out and sometimes you can get insulted, like look. I don't care about that. You know, I want to click a button and it sends out a contract for signature or something. You know what I'm saying? That's what they're , they're looking for. How is this going to create a [inaudible]

Alex Shull:

And that's a good point because it's the, it is the user interaction. That represents how people understand software for the most part. And if you get to a really savvy technical users, they might be interested to know, you know, what your, what language you're coding in on Amazon web services. But most of your users, they want to see that button click.

Gil Roberts:

I speak in Amazon web services , uh , kind of the front part of this question for it took a little shot there. Um , was kind of the tools that we use, just why Sassafras came into being and it just kind of where, where we found some, some I want , I want to say shortfalls of globiflow. Those things...

Alex Shull:

Yeah. So the nice thing about globiflow that it is, you're able to very rapidly put that stuff together. Um , but by design globiflow is matched to a, an instance of podio. And so even though you can capture those flows and you can import and export them, and there are some tools for deploying them, by definition, there is an instance of flow per the instance of podio. Uh , you know, whether it's , uh , an individual application or our workspace, that's how it maps into global flow. And so for our purposes, if we wanted to provide updates to a core function on the back end that responded to an event, when someone , um, you know, provided a service for example, then we want to be able to deploy the updated functionality to all of the users. We don't want to have multiple versions out there and we also don't want to , um, we , we want to minimize the number of assets we have to deploy to , to provide that functionality.

Gil Roberts:

Set a little context , uh , impact pro, you know , we built it. Podio it's a solution and then we've people buy copies of that solution, right? Yes. And that's the way that it's set up. So we have like uh, six, seven odd work spaces that people buy as they said . Yeah , we've copied that, those seven over and over and over and over.

Alex Shull:

Yeah and that right there. Even when you're dealing with globiflows, importing and exporting you , you might know that the um, cross workspace linking and put in globiflow has had some issues with um , copying that, replicating that out. Um, and , and obviously nothing across organization should work anyway, but , um, there , um, there were some limitations there. Um, and so in, in designing the services to solve our problems , um , and , and be able to take a solution design and global flow to the level where we only had a single set of custom functions in the back end , they would respond to events from any one of those customers using the solution. We are, are , um, Sassafras backend captures those workspaces into what we call assessment for us solution. And so those workspaces that comprise impact pro have a versioned , um, instance that we maintain outside of podio. We use the API to capture all the key data points and elements that are um, defining those workspaces. And when we deploy it, we use the API again, we call that Podio Api and we use the stored version of the application to actually create the workspaces, the applications, the fields, all the interlinkages between the workspaces as well. All of the web hooks, everything is created through API calls from our Sassafras engine based upon the stored version of that Sassafras solution. And so this is a lot of work for us to build a platform that really extended the capabilities of podio only using the podio API though we didn't, we, there's no magic to what we're doing. And the Podio Api enables you to do these things. Sassafras just does them in an organized way to where when we bring on a new customer for impact pro, we , you know , the Sassafras side, we designated a new client with their own environment and we can call it, make a single API call to deploy impact pro to this client's environment. And in the back end is all runs on AWS lambda. And so it's , it's a very scalable solution. We start calling making the podio API calls that translates this , um , stored solution into a really a real deployed instance of Podio, workspaces , applications and everything. And so it's, it's our own a way of adding those cattle enterprise class capabilities on top of Podio to where you can maintain those assets separately and you can deploy them and maintain them in controlled version . So those are , those are the tools that we really had to build to take a globiflow designed solution and turn it into what our client needed , um , for delivering to their customers.

Gil Roberts:

And as a part of that , um, we , we had to take some of the flows while we took basically all the flows for impactpro off of Globiflow and converted them into the AWS lambda. And a lot of that was because, you know, if you have a 100 of these environments and deployed , it would take hours to do as simple update of all, you know, you have to, yeah ,

Alex Shull:

yeah. I skipped over that step. Yeah. So initially I spend a lot of effort decoding the way that globiflows were exported. And so I, I actually, if you recall, I built a tool that would take the export and globiflows and it would remap them to a new environment and provide you XMLs that you could import back into globiflow and they would all map correctly up to your environments. Unfortunately, we couldn't automate that well enough because globiflow doesn't have an API for managing flows like that importing and exporting them. But , um, the better solution for us overall.

Gil Roberts:

I should say at the time, at a time as , as well.

Alex Shull:

Yeah. And then they're , they're expanding their , yeah . Changing their capabilities and hopefully they do add that. But um, what we ended up doing was , um, having your own event engine Sassafras would , um, we would take all the stuff that we modeled the flow , we rewrote everything in c sharp and it runs as functions that run on AWS lambda . If you're not familiar with AWS lambda is what it's called a serverless model for cloud computing are still servers with it. It's called serverless because I don't care where they are, I don't have to maintain them. And so AWS lambda is a really, really good fit for the way that we develop clients software. And it's also a really good fit for having something like a Sassafras event engine that can respond to any number of different events coming from podio and then route those events to the correct function to deliver the salute , the capabilities .

Gil Roberts:

It's listening over those web hooks.

Alex Shull:

Yeah. So same webhooks, that globiflow uses, it's the same model. It's just that once we wanted to have a single function that could handle all the requests from a 100, 200 deployed instances of impact pro, all of those are handled by the same function. They get consistent delivery and an AWS lambda scales the function out. Yeah. It will have to take a little time to scale it, but it's, it's always going to match our capacity needs.

Gil Roberts:

Sure. And , and it's all event based , so like things aren't running all the time.

Alex Shull:

Yeah. It's just as you should go. You know , one of the nice things about AWS lambda and the way that so much software is going and the way that we try to offer our solutions is that you pay as you go. And , um , if you , um, if you aren't using AWS lambda, then , um, it's , um, you're just paying for the storage of the, of your code, which is very cheap. And if you're using it, then you're paying for only when it executes. So , um, you know, it ultimately, there are situations where that's not the most cost effective way to deploy a solution. But again, for , um, the , the approach that we take with our clients in a very lean, agile methodology, it's a perfect fit.

Gil Roberts:

But , and , and the way they , uh , especially with impact pro , the way that they , those counseling agencies operate. Some are real busy at certain points of the day. Some are not, some are only busy during certain times of the month. We get a large bump at reporting time, which is quarterly. So we want, we need something that's gonna scale out without somebody having to do that because you don't know why everybody's going to flood in and do their report . No activity for weeks after that.

Alex Shull:

You reminded me of something, I didn't even mention Gil, which is that one of the big features that we had to deliver for impact pro, which turns out to be a greater challenge than I initially anticipated. But we , we've been successful in this is , um, we have a solution for replicating entire , um , um , workspaces or applications you can select which , um , into a my sequel database on Amazon. And we provision these , um , uh , at the solution level and we maintain the data at 15 minute increments to a , um, basically realized the views and , um, database terminology that can be queried , um , in aggregate across all of the environments. And so basically if you, if you want to imagine that we have a single application that we've deployed to 50 locations that let's suggest say that they're a franchise locations and the franchise , um, um, you know, headquarters wants to do reporting in aggregate across all 50 locations. Well, the solution that we provide to replicate data into my SQL provides that level of organization to where we could actually provide aggregate reporting to the headquarters in this situation, replicating all the data back to my sequel in the same pattern that it's defined in the podio applications. That's a very big aside and probably deserves its own podcast.

Gil Roberts:

Sure.

Alex Shull:

But I only wanted to mention it because today, and this is very, very new technology, but today we can do that delivery SQL services on demand. And so we can make it very, very cost effective as a, I'm a software development company providing those services and also to our clients who want to , um, sell those services to their customers.

Gil Roberts:

What you're saying is, hey, listeners , listen up. If you're an agency like us that develops solutions for clients on behalf of clients, typically you tend to gravitate towards certain industries, right? Uh, you know, start thinking about these tools in core and solution set so that you guys don't have to do the same thing. Oh , remake the wheel over and over and over.

Alex Shull:

Yeah and as , as an agency, you really have to keep up to date on the available tools to make sure that you can offer them to your clients. And the obviously the things that are coming around the corner that are all very , um , topical or blockchain and artificial intelligence, these are all services that in the same way that we can use AWS lambda to deliver very custom functionality to a set of clients without having to build it from scratch. We can deliver these other solutions to our clients. And , um, keeping abreast of those , um, the , those toolsets sets and the, and the changes in the , um , platforms is really key to being an effective agency.

Gil Roberts:

Yeah , that'd be very interesting. I think that might also deserve its own podcast is how can we integrate blockchain and AI with the podio interface . Right. Like I think I think might be something interesting

Alex Shull:

we talked about use cases where that, well

Gil Roberts:

Again, another interesting episode. I'll put that down on the list and you know, listening to be out looking for that, here soon. Uh, what's, what's, you know we talked a lot about Sassafras or are kind of a proprietary tool set that we're using. We are looking and in the process of building an interface for some of these elements to open this up to some of our, our listeners, some of the other agencies out there that are looking at podio or developing podio based solutions Kinda Kinda hit some of the highlights and I'm going to see to couple here. Let's dive into W we've talked about deployment. So like actually shooting out copies of podio based solutions. Talk about patching . I think that we see that on the forums a lot. Yeah . We've had some inquiries to us directly.

Alex Shull:

Yeah. Well are we have pets in the solutions developed a while ago. Um, and they've gone through a significant transformation now. And so patching is a, is a very difficult problem to solve with podio. And the reason is that to this point , um, all you weren't sure that the environment was preserved. If you went back to a solution that you deployed, it could easily have been changed. And , um, if you were starting to do perform an update and you update a field where the name has been changed, where it's been moved or anything, you're going to have very unexpected results. And so it wasn't really designed to have versions and patching in it by default. And so when I went about designing the patching solution , um, I started with the notion of the Sassaafras for solution where we're taking a moment in time of a set of workspaces and saying this defines a single solution. And that is a reference point is something that I can build out as a resource that is stored in a it Jason format. And that's the what the podio API uses by default. And I can do a head to head comparison with the current status of a matching set of workspaces that I want to patch. And so my tool, we'll do ahead, come head to head comparison and it will show you every difference between the workspaces, the applications in the fields. Now the problem with doing this is that you have to have some logic that figured figures out what the best matches. You can try to match by names. You can try to match by external ids. But there, there are some finicky aspects of podio. I'll just be honest here. Um, and the , it can make it challenging. And so that's kind of where the , um, the secret sauce of Sassafras is so to speak, is that we figured out some mechanisms to deploy applications in a way that lets us track them and make them patchable. And so if we, if someone comes to us and they say, I have all these environments that I deployed years ago and now I want to patch them to this new updated version, we can , we can help them. Actually it would just be more work. Have you start off in our solution and you deploy a Sassafras solution, then patching is actually a pretty smooth , we figured out how to keep that.

Gil Roberts:

And to clarify, patching is the actual p odio environment itself, not just the functions t hat sit behind it.

Alex Shull:

Yes. Yes. Patching just means that you've added fields to an application. You've maybe changed categories or you made a hidden field. Anything that has to do with what you do, you go in and you modify a template, had applications, any of that

Gil Roberts:

So I'll bring us back down to earth with a quick example. So let's say that you are building a CRM system for a chain of dentist office or CPAs would say, and uh , those CPAs are tracking their clients . It's tax time. So this is relevant, right? They're tracking their clients and getting their business in the door to be able to do tax returns. And you want to make, let's say you got a hundred of these copies out there, a hundred a hundred of these CPA agencies are using, using your solution , uh , you can basically deploy across all 100. You want to add these 10 fields, take this field out, and then update a particular field from add categories to particular field will say.

Alex Shull:

That's right.

Gil Roberts:

Yeah. And you could just, you know , the idea is that you should be able to push a button, right? Just like software for a long time has been patched . Well , you know, it used to be sending the DSG out or download the patch from the Internet. Now this is a similar kind of mentality,

Alex Shull:

It's similar in the , um , it's designed to be , um, push button. You have a new version and you can have an environment up there and do that version. But it's also very interactive in that you will get a lot of, of , uh , inspects the current environment. So it doesn't just try to blind the leader , try to apply some binary patch the solution. So it's , it's an interactive , um, you know, kind of logical process for comparing applications and fields and using logic to determine that the best way to , um , to patch. So it's a , it's something that , um, I'll tell you a little aside, one of the pieces that I know is, is core to the way that podio has designed their central databases, the use of external ids and fields. And I know that because they don't let you manipulate them. Once you had a field, it gives you an external id and you cannot change it. You can , um, it's , um, something that apparently goes into a key system that's unrecoverable , um, from, from the standpoint of podio. And so that meant that in our scenario, deploying an application multiple times, the only way that we could have assurance of the external id if we deployed that field of ourself . And so I'm relying upon that as a guarantee. Um, I think it's a weak spot in , um, what would be the naive way of building a podio deployment tool. And I think that affects patching as well. If anything goes wrong during the patching process, all those external ideas could be , um, suspect. I'm not sure. So it's a little, a little aside on the podio side.

Gil Roberts:

And the general has been a complex matter. I know you've wrestled with that. Yeah, we talked about frustration . Yeah.

Alex Shull:

But you know, we , we, we figured out a good way to deal with it and to um, to really , um , still be able to get the best out of podio.

Gil Roberts:

That's fantastic. Uh , just wrapping up our discussion about that tool , um , and , and how we use it inside an impact grow. What's, I guess what's one of the kind of highlights of, from our customer's perspective of having them on a custom engine that allows for deployment, patching those two things also allow for like version control systems , uh , that we've,

Alex Shull:

well, it's good . It's an interesting point because especially for the customers of this software, there is a lot of what is standard process that they have to get right. And then there was a lot of process that they add on for their specific situations. And so when we built impact pro, we covered the core process. That's the part that, you know, it crosses the t's dot the i's and it , you know, it checks all the boxes that you need to have checked. And then we have agencies who will add in their own applications,

Gil Roberts:

Customization

Alex Shull:

Customizations in podio and they will , um, they like podio enough to go, you know, capturing more there and get more out of it, but they don't impact the core functionality. The core functionality chugs along fine keeps crossing the t's and dotting the i's for them. And so that balance I think has really impressed a lot of the users and it's shown them why having this approach of a rapidly, you know , developed application gives them the flexibility to continue improving upon it. Um, and again, having those gates to where people understand , um , what can be changed and what can't be changed. Podio doesn't have, a lot of granularity there. And so , um, you, you have to find the right way to give people access to that flexibility without giving them , um, you know, the rope to hang themselves with.

Gil Roberts:

I was about to say you can give them too much. As a , especially with our clients and our clients' clients, the end users who are buying this solution, they kind of asked for a small customization and they're used to the old software model where it's going to take months to get like fields at and all that. And then we do it in like two hours, but it doesn't, it , you know , and there's no impact to the rest of their software. Unlike it taking a month or two and then it breaks something else and they fix it and they go, okay, now I finally got my fields that I wanted , you know , so now they're like, oh man, I can do more. Right. It kind of all , you kind of opened the occasional line to the lions den and I just kind of looking out the door, they just don't know what to do with themselves. They get lost real easy.

Alex Shull:

How much time do we have left today? We've got, we've got about 10 more minutes. Well, let me just mention one other thing that , cause I think that's a great segue into the topic of Qa because once you have an application that you are versioning, you're deploying out to lots of locations and you're making changes to it, one of the key points you have to address is how do you make sure that the things that are supposed to keep happening continue happening. You don't break the existing functionality when you roll out new functionality. And that really is

Gil Roberts:

Nothing more frustrating. I got to , I got to the point that in there your user and it used to work and now doesn't.

Alex Shull:

Yeah, that's, that's a, that's definitely a problem. And , um, it's probably for a lot of systems and so the tools that are available for , um, you know , developing applications and you know, c sharp for example where you're using unit tests and integration tests and you , you have a lot of layers of Qa available to make sure that your application works the same when you're going into an environment like podio and you have a lot of changes and integration points, there's a lot of things that can break and there's a lot of things that can break down unexpectedly. And so at the same way we had to address a means of two things. Ensuring that deployment that we performed was correct after the fact, going in and audit a deployment and make sure that it's correct, but also a means of making sure that something that was deployed actually is working correctly. And a QA system for podio is , um , a trickle on itself. But theres something in Sassafras, um , aims to address and I'm really happy with the , um , the way that it's going.

Gil Roberts:

Excellent. Uh , what's, what's jumping to , there's some real talk here about limitations. We covered some design on, on is on the last , uh , episode. Let's talk about some development limitations corral us into just some of the podio API limitations . It's impacted you directly was saying top one or two things that really just kind of were like, man, you either had to really just hack around it or something like that.

Alex Shull:

Well, I mean, one , the one that I mentioned already is the external id, which would have been very convenient if we could have total control over external ids for fields that , that'd be very useful. But I'm there , we found a work around there. Um, there are, there are a few features in the API that I would say we're not well documented. For instance, we wanted to be able to have fields that were , um, hidden on the edit screen and it's in there in the API, but it's not documented and at least for the , um, the, the.net library. And so in the meantime, for instance, we need to , um, share our code back to the community. But we've had to , um, make customizations to our , to the core.net client library for Podio to actually add features that weren't documented, for instance, hiding field . So there's a little bit of gap is, but it's pretty, you know, podio without it is actually pretty good. Uh, but there , there are little gaps. Um, the, the only other thing that I would, I guess say is a , um, a limitation is a little more technical. When I think about supporting a , um , a caching environment and this is only that podio and the technical documentation, they talk about a lot. They say, you know , you're going to listen for events and you're going to get items if you want to have better performance cash your items. So we have a, a pretty, you know, well developed podio proxy built on or on a red as cash and we'd been through a lot of resources at it. Um, and um,

Gil Roberts:

yeah , we figured that out .

Alex Shull:

Yeah. Be careful. Pay as you go. You still have to pay the, but the, the podio of API doesn't use the convention of he tags or other ways of designating when a resource is the current version or not. And so I think it would perform a little bit better if , um, there was a standard for , um , some of those , um , resource caching definitions. But the , um, there, there is enough in there for a item revisions and things like that that you can get around it. But for , um , supporting a really solid http caching infrastructure, I , I would prefer that they support it . He tags. Um, but you know, those are, that's kind of a, a a nerd point.

Gil Roberts:

That's right. That's what this episode is all about is really getting under the hood stuff . Very interesting. Uh, what, let's, let's jump in again real shortly into it just controlling the development process and why , uh , we want to tie it back to the last episode. Why Jareds discovery process with the client really impacted , um, your part of it on the development side. And to give just a quick back story , we still had podio changes going on while you were developing and I know kind of some back and forth. He was making some changes and you're like, wait a minute. And I was kind of building towards one way. And just how , how did both of you guys kind of control that development process together?

Alex Shull:

Um, it's complicated to discuss that because you know, I'm simultaneously, we were developing the Sassaafras platform as well as impact pro. And so it's , um, as far as the , um, the , the, the, the development of the Sassaafras platform in interacting with the other things is , um , um , much more nonlinear, let me say. But in terms of, of working on the impact , um , pro application itself and through the discovery process , um, you know, the , the, the main thing that it provides, I think is , um , some of the aspects of user experience that are key to , um , understanding , um, successful user interactions. And so in your discovery process, a lot of times , um , you get to learn that , um, people work in certain phases where there's a certain like key point where a certain process is complete and the user interface that you build for someone. Um, if it doesn't give them a good convincing experience of having completed that task, then sometimes it remains confusing for them. So a lot of the discovery process that came to your impact pro and be touched on an external integration for Hud for instance, it became very important for me to understand how to provide back that user feedback to where they knew on the back end what was actually occurring that has an impact on their job function. We really take seriously the idea of discovering the work process and really sussing out how people work. Because if you really dig into that, you can help them along and you can figure out what should be automated and what kind of information they need. And so through that discovery process I, it really helped me understand , um, you know, using for instance, the comment log in side of podio applications is a really good way to give people feedback and that work is being done. It's, It's semi doesn't, a page doesn't have to be reloaded comments just come up there and they can see the services affecting the changes on the back end. Things like that.

Gil Roberts:

Pulls way that mysteriousness of when I click this button, yes. But you got there , there is a line to ride because we haven't heavily nontechnical user , especially in that industry that, you know, they really don't care a lot. They just want to make sure that they did their job .

Alex Shull:

Yeah. And that the messages have to come back and tell them that the work that they're expecting to be done is getting done. And that in planning it's a user experience thing and podio does, it has a lot of the good features of tool tips and it has a good simple reusable design. And then using that comment log is , um , provides an additional layer of interaction to where they can see the, the application is working. Yeah ,

Gil Roberts:

We can talk to the users and we can tell them if they're doing something wrong. We can tell them that they're doing something right as part of the business process. We can tell them when, when, when the robots take what they're doing and do their thing and bring it back to them, right? Like, Hey, the work's been done. You can rest assured all the stuff for your reporting is completed or what have you. So that's a good point. Well, I think that does it for this episode. Thanks again. This is definitely a longer episode. We knew this was going to be the case , uh , here, roughly about 45 minutes. Um, so we appreciate you listening in. If you're listening to that's made it all the way through. Um, for our next episode and it'll be much shorter. We're going to dive into the actual CVP , which is what we call a commercially viable product . So this is where we're out of Beta. We actually have paying users onto the platform, which we've moved into that. We moved into that about this time last year when we first started getting our first paying customers. Even at a reduced rate. We're at full strength now . Everybody's buying it at market price. But we wanted to kind of just briefly touch on what it will Clyde to take a podio base solution out of a Beta. Uh , cause we did close Beta work with, with some of these agencies and what it look like moving into, into the business side of selling and marketing a podio based solution or there'll be a shorter episode. Um, but I think that understanding that or help kind of complete out this experience and that will also be the last part of this three part series about uh , impact grow and how we built a solution on a six figure budget could be very, very interesting to do as development agencies after and also large enterprises looking to invest in the podio platform, if you would like to know more information about impact pro it is at impacpro.org and that's the letter m as in Mary. So, m p a c t p r o. o r g Just as a reminder, we d id build this for a nonprofit industry. Thank you again for listening to our podcast. If you have not, please, please, please hit that subscribe button. Also, we are now on apple, iTunes, Spotify, if you have an Alexa? You can actually listen. Yes, sure . Please, please leave us a review . Uh, it's a new show. Those reviews are very helpful for us to get exposure and allow us to continue to series to talk about podio development and that ran a podio community, which we think is very important for future solutions to be built. Yeah . Couple quick reminders. We are looking familiar gaps. We want to solve them on her show. Maybe even have you on his shows or family problems. We're looking through your user forms. Go on . Oh Man , I can't get part of you do this or unless you could be that please submit those. You can hit us on Facebook, linkedin, Twitter, send an email or podio message to podcast there . Brick Bridge consulting.com we are still working on the Sassafras website, we'll let you know when that is available, so you take a look at those services on once we begin to open them up to the rest of the community on one last time, please subscribe and we will talk to you next week. Thanks, again.