[ad_1]
Software consultant Andrew Drach's two companies Callentis and Solwey demonstrate his entrepreneurial skills, but his customers also value his educational background, as we learned through TechCrunch's survey to identify the best software consultants for startups.
Kelly Twigger of eDiscovery Assistant tells us why her company selected Solwey, citing “Andrews Ph.D. and analytical background in relation to data ”as well as his consulting skills for startups.
However, expertise is only useful when it's implemented – and so does Solwey, Twigger said. "We don't just add tasks to a Trello board that need to be done, but discuss the goals, why and how they can best be achieved, taking into account the cost-benefit analysis." This point was supported by other survey participants, therefore we contacted Drach and his team to find out more.
Editor's note: This interview has been edited for length and clarity.
Can you tell us something about your career to date and current company?
Andrew Drach: Since I started programming, I have been providing consulting services in the areas of engineering and software from time to time. And after a few years in science, I realized that I didn't want to take the tenure-track faculty path. I told my wife [Monika Jociunaite] that, despite my passion for science, I had decided to leave science and develop freelance consulting into an agency, and that she should switch to me.
Monika was a perfect co-founder with complementary experience and skills. Her background includes two Masters degrees – in International Business and Marketing – and she has worked in large international companies for more than 5 years. She was curious to explore a more creative side of marketing as she has enjoyed working on UX / UI projects in the past. and I knew firsthand that high quality code without good UX / UI for the end users is no different from broken code.
In December 2016 Monika and I founded two sister companies: Solwey Consulting, focusing on technology strategy and execution, UX / UI design and business intelligence; and Callentis Consulting Group, a research and development company focused on translational research and technology transfer from academia to industrial practice.
More specifically, Solwey provides advice at 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, as well as business intelligence / data analysis to ensure rapid growth and movement for our clients allow forward.
Why did you choose the boutique advisory model?
We have both had tense experiences working with large agencies and recruitment agencies and felt abandoned or not important enough to have the full attention of the manager or project owner. Plus, we'd both both seen firsthand how terrifyingly crippling waterfall and broken agility can be in the progress of a project. So we set out to set up Solwey and Callentis as small design agencies. We work directly with our customers, and Monika and I take personal responsibility for every single result of our team.
How is your team structured?
We wanted to set up a virtual-first-remote-first agency from day one. In pre-pandemic times, it seemed unconventional, but 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 talents who have joined our team and have been able to celebrate the fourth anniversary of some of our employees while we are only a five year agency.
We currently have eight full-time developers, a DevOps manager and our Chief Operating Officer Nima [Kargah-Ostadi] who is a Ph.D. in engineering with a decade of experience leading engineering and research teams and is a certified Project Management Professional (PMP).
How did you find customers?
When we first started, I just googled remote software developer platforms and registered on some of them. In a few days we already had a contract, so we were immediately excited about the freelance platforms; Upwork was a major source of projects because it was easy to find a contract there. But over time, as we grew and the rates and team size increased, Upwork no longer suited us. Nowadays we get referrals from former customers, new contracts from returning customers, some inquiries from organic and paid search, and entries on B2B platforms such as Clutch.
My focus in 2021 was diversifying our lead sources and we have experimented with many different approaches. The least successful so far have been hiring business development representatives and trying out cold outreach (email and LinkedIn), but maybe we just got it wrong. On the other side of the spectrum, we have very successfully established partnerships with VC funds and marketing agencies. Other approaches (social media, paid ads, content marketing, networking) also yielded interesting results.
Help TechCrunch find the best software consultants for startups.
Make a recommendation in this short survey and we will share the results with everyone.
Are startups your main customers and what do they need?
60% to 70% of our customers are startups or small companies in different phases. We helped startups in the pre-seed phase to create prototypes and guide their technology development plans. In the seed phase we work with them to develop their Minimum Viable Product (MVP) and in the following phases we can help them with some of their many start-up initiatives.
Some of these companies come to us before they even have a technology team, some begin to hire and grow their development team, and some have a fully staffed technology team that is overwhelmed with existing work and cannot take further initiatives.
We always strive to help startups hiring and completing their technology team, especially if they have an idea that revolves around technology. In fact, I worked as Interim Chief Technology Officer (CTO) for three startups.
Why do you think architectural design advice is important?
Early stage clients typically focus on their MVP and launch plans. Too often we have to go this delicate route to help them beat the competition and impress their investors as quickly as possible, while at the same time trying to deter them from making architectural or strategic decisions that might come back to them difficult to bite when the time comes to improve some features, add new features, iterate, or aggressively scale. In the meantime, we're doing our best to provide guidance, avoid some common problems, and explain why investing early in architecture or formal operational processes would help in the near future.
We tend to focus our recommendations on the period of around six to twelve months so that we do not get stuck with early optimization. A tailor-made architecture design enables a more efficient development process, fast iterations and leads to a robust and scalable software solution that is leaner and less uneven.
What is your billing model?
Monika and I firmly believe that transparency and an easily understandable billing system have helped us a lot in building trust and strong relationships with our customers. We use a project-related billing model with a flat hourly rate.
As part of the diagnostic preliminary discussions with our interested parties, we try to understand their priorities and to work out a reasonable scope for step-by-step projects. Nima and I then put together a Gantt chart to visualize a realistic task schedule and estimate the number of hours it would take to design, develop, test, and deploy the expected solution given the customer and resource conditions. The proposed budget is simply this number of hours multiplied by our hourly flat rate, which includes all overheads.
What is your typical schedule?
For a typical startup product that is in the initial phase of the development of an MVP, we generally recommend two weeks for the determination and recording of requirements, four weeks for the UX / UI design together with the infrastructure – and architecture design, eight weeks for agile development and continuous tests for the implementation of the most important functions and finally two weeks for the provision of the MVP solution and short-term optimizations.
Picture credits: Solwey
We are working with our clients to postpone any tasks that have been collectively identified as non-blocking or non-critical in order to keep the MVP lean enough to get off to a successful start in such a short period of time. This is because, in our experience, four months is long enough to develop most MVPs and short enough to allow for a quick roll-out and receive much-needed feedback from users and investors that will ensure the startup's success in subsequent stages guaranteed.
Two of your customers mentioned that they came to you after having had less than good experiences with other companies. Could you explain how that is? And do you have any tips for startups who want to avoid bad experiences?
The very first thing I tell our customers in the diagnostic interview is that sometimes something does not work, but their negative experiences do not mean that the cooperation with external teams always fails or that their previous technology partner was unqualified or had bad intentions. I sometimes joke that our team should be called Iteration # 3. Most of the projects that we take on usually went through two iterations: once with an agency outside the USA due to cheaper tariffs and another time with a junior or mid-level freelancer. And while there is absolutely nothing wrong with either approach, founders tend to underestimate the level of practical coordination required in these scenarios to complete the project.
Some advice to avoid a bad experience? Set clear expectations and communicate. Regardless of whether a startup is employed with a recruiting agency, a temporary employment agency, a freelancer or an agency like us, it all boils down to a clear demarcation of tasks and frequent check-ins to ensure that potential problems arise quickly and the team can themselves turn fast. Will there be unexpected problems, delays, complications? Definitely. But how these obstacles are communicated and addressed is important.
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 for managing projects, so the discussion of "fake" vs. Through our interactions with different teams we have come across cases where the agile process was extremely inefficient for a number of reasons. Sometimes a manager or team leader focuses on agile ceremonies designed for large distributed teams, while the overall team size is just two developers working in the same room. In other cases the process was so fluid that the priorities would shift several times a day. And sometimes the team defined weekly or bi-weekly sprints, but then had a rigid quarterly plan that looks exactly like a waterfall approach.
To be honest, I am not sure if our process would fall under the strict definition of agility because we are adapting it and trying to take into account customer preferences in order to reduce potential friction losses. We have several key requirements, including daily check-ins with our designers and developers, weekly sprints with clearly defined tasks, regular release schedules, continuous integration processes, striving to have design assets ready 1-2 sprints before development, etc. But beyond that, we do our best to accommodate the client and provide recommendations, as the process would be very different for a one-person team than for a late-stage startup with dozens of team members spread across multiple time zones.
[ad_2]
Story continues…
