From Ph.D. to boutique software developer: An interview with Solwey’s Andrew Drach
Software consultant Andrew Drach’s two companies Callentis and Solwey demonstrate his entrepreneurial skills, but his clients also value his educational background, as we learned through TechCrunch’s survey to identify the best software consultants for startups.
Telling us why her company picked Solwey, eDiscovery Assistant’s Kelly Twigger cited “Andrew’s Ph.D. and analytical background related to data,” as well as the consulting expertise for startups that he provides.
Expertise is only useful when it’s implemented, though — and Solwey does this too, Twigger said. “We don’t just add tasks to a Trello board for them to complete, we discuss the goals, why and how best to achieve them with cost/benefit analysis in mind.” This point was seconded by other survey respondents, so we reached out to Drach and his team to learn more.
Editor’s note: This interview has been edited for length and clarity.
Can you tell us a bit about your recent background and current companies?
Andrew Drach: I have been doing consulting in engineering and software on and off pretty much ever since I started coding. And after a few years working in academia, I realized that I did not want to go the tenure-track faculty route. I told my wife [Monika Jociunaite] that as much as I was passionate about science, I had decided to leave academia and grow freelance consulting into an agency and that she should join me.
Monika was a perfect co-founder with complementary experience and skill set. Her background includes two master’s degrees — in international business and marketing — and she spent 5+ years working in large international corporations. She was curious to explore a more creative side of marketing as she enjoyed working on UX/UI projects in the past; and I knew firsthand that for the end users, high-quality code without good UX/UI is no different from broken code.
In December of 2016, Monika and I established two sister companies: Solwey Consulting, focused on technology strategy and execution, UX/UI design and business intelligence; and Callentis Consulting Group, a research and development business focused on translational research and technology transfer from academia to industry practice.
More specifically, Solwey provides consulting in all stages of software design and development strategy and execution. We work with our clients on architecture and infrastructure design, optimization of UX/UI design and user flows, back-end and front-end software development for web and mobile, and business intelligence/data analytics to enable our clients to rapidly grow and move forward.
Why did you choose the boutique consultancy model?
We both had strained experience working with large agencies and staffing agencies and feeling abandoned or not important enough to have the full attention of the managers or project owners. Furthermore, we both had seen firsthand how terrifyingly crippling waterfall and broken agile could be for the progress of a project. So we set out to build Solwey and Callentis as small-by-design agencies. We directly engage with our clients, and Monika and I take personal responsibility for every single deliverable from our team.
How is your team structured?
We wanted to build a virtual-first, remote-first agency from day one. While it seemed unconventional in pre-pandemic days, this allowed us to stay as lean as the best startups out there, while drastically improving our hiring prospects. We have been incredibly lucky with the talent that joined our team and to celebrate several of our employees’ fourth anniversary while being just a five-year-old agency.
Currently, we have eight full-time developers, a DevOps manager and our Chief Operating Officer Nima [Kargah-Ostadi] who has a Ph.D. in engineering with a decade of experience leading engineering and research teams and is a certified Project Management Professional (PMP).
How have you been finding clients?
When we started, I just googled platforms for remote contracts for software developers and registered on a few of them. In a couple of days, we had already got a contract, so we immediately got hooked on the freelancing platforms; Upwork was a primary source of projects because it was so quick to find a contract there. But over time as we grew and increased the rates and team size, Upwork became less of a fit for us. Nowadays, we get referrals from former clients, new contracts from returning clients, quite a few requests from organic and paid search, and listings on B2B platforms like Clutch.
My focus in 2021 has been on diversifying our source of leads and we have been experimenting with many different approaches. So far, the least successful has been hiring business development reps and trying out cold outreach (emails and LinkedIn) but maybe we were just doing it wrong. On the other side of the spectrum, we have had great success establishing partnerships with VC funds and marketing agencies. Other approaches (social media, paid ads, content marketing, networking) also provided interesting results.
Are startups your main clients, and what do they require?
60% to 70% of our clients are startups or small companies at various stages. We have helped startups at pre-seed stage to create prototypes and guide their technology development plans. At seed stage, we work with them to develop their minimum viable product (MVP), and in subsequent stages, we get to help them with some of their many newly formed initiatives.
Some of these companies approach us before even having a technology team, some are starting to hire and grow their development team, and some have a fully staffed technology team that is swamped with existing work and cannot take on more initiatives.
We always strive to help startups hire and complete their technology team, especially if they have an idea that revolves around technology. In fact, I have served as interim chief technology officer (CTO) for three startups.
Why do you think architecture design advice is important?
Early-stage clients are typically focused on their MVP and launch schedules. Too often, we need to walk this delicate path of helping them move as fast as possible to beat the competition and impress their investors, while at the same time try to stop them from rushing into architectural or strategy decisions that could come back to bite them hard when it is time to enhance some features, add new functionality, iterate or aggressively scale. Meanwhile, we are doing our best to provide guidance, prevent some common issues and explain why early investments in architecture or formal operational processes would help in the near future.
We tend to focus our recommendations on the time span of roughly six to 12 months so that we do not get stuck with premature optimization. A custom-tailored architectural design allows for a more efficient development process, fast iteration and gets to the robust and scalable software solution leaner and with fewer bumps along the way.
What is your billing model?
Monika and I strongly believe that transparency and easy-to-understand billing have helped us a lot in building trust and strong relationships with our clients. We use a project-based billing model with a flat hourly rate.
During the preliminary diagnostic conversations with our prospective clients, we try to understand their priorities and carve out a reasonable scope for projects divided into stepwise phases. Nima and I then put together a Gantt chart to visualize a realistic schedule of tasks and estimate the number of hours it would take to design, develop, test and deploy the anticipated solution given client and resource conditions. The proposed budget is simply this number of hours multiplied by our hourly flat rate, which includes all overhead costs.
What’s your typical timeline?
For a typical startup product that is at initial phases of developing an MVP, we typically recommend two weeks for discovery and requirements gathering, four weeks for UX/UI design along with infrastructure and architecture design, eight weeks for agile development and continuous testing to implement the major functionality and finally two weeks for deploying the MVP solution and last-minute tweaks.
We work with our clients to postpone any tasks that were collectively identified as non-blocking or non-critical to keep the MVP lean enough to have a successful launch within such a short timeline. This is because in our experience, four months is long enough time to develop most MVPs and short enough to enable rapid launch and get much needed feedback from users and investors that guarantee the success of the startup in subsequent phases.
Two of your clients mentioned coming to you after not-so-great experiences with other firms. Could you explain what this is like? And do you have any advice for startups wanting to avoid bad experiences?
The very first thing I tell our clients in the diagnostics call, is that sometimes things do not work out, but their negative experience does not mean that working with external teams is always going to fail or that their previous technology partner was unqualified or had bad intentions. I joke sometimes that our team should be called “iteration #3.” A majority of projects that we take over usually went through two iterations: once with an agency outside of the United States, due to cheaper rates, and another time with a junior or midlevel freelancer. And while there is absolutely nothing wrong with either approach, founders tend to underestimate the level of hands-on coordination required to complete the project in those scenarios.
Advice on avoiding a bad experience? Setting clear expectations and communication. Whether a startup is engaged with a staff-augmentation agency, or a temporary hire, or a freelancer, or an agency like us, it all boils down to having clear delineation of tasks and frequent check-ins to ensure that any potential issues surface quickly and the team can pivot quickly. Will there be unexpected issues, delays, complications? Certainly. But it matters how these obstacles are communicated and addressed.
Do you have any thoughts on fake agile versus real agile? And why do you believe in the latter?
In my opinion, the word “agile” has been loosely applied to many different approaches and strategies to manage projects so the discussion of “fake” versus “real” agile is tricky without a specific context or example. Through our interactions with different teams, we have encountered cases when the agile process ended up being extremely inefficient for a number of reasons. Sometimes, a manager or team lead would be laser-focused on agile ceremonies designed for large distributed teams while the total team size is just two developers working in the same room. In other cases, the process was set to be so fluid that the priorities would shift several times a day. And sometimes, the team would define weekly or biweekly sprints, but then would have a rigid quarterly plan that looks exactly like a waterfall approach.
To be honest, I am not sure that our process would fall into the strict definition of agile because we adjust it and try to accommodate client preferences to reduce any potential friction. We have several important requirements, including daily check-ins with our designers and developers, weekly sprints with well-defined tasks, regular release schedules, continuous integration flows, striving to have design assets be ready 1-2 sprints ahead of development, etc. But beyond those, we do our best to accommodate and provide recommendations to the client as the process would be quite different for a one-person team versus a late-stage startup with dozens of team members spread across multiple time zones.
Source: TechCrunch
