incite vs insight. there is an excellent pun in that malapropism :)

The only credentials or "licenses" you need to create an integrated design-develop-build company to do single-family houses are a general contractor license and a business license. This, in itself, actually explains kind of a lot about why the homebuilding industry is so messed up, but that's a separate topic. The basic point is: if you want to do it, the only thing standing in your way is paying a few fees to the state for some easy-to-get paperwork. Once you've got that, then the next challenge is getting equity capital to start your first project, which you use to get your first land aquisitions under contract. You can either finance it yourself, or go find some investors. Do you know any dentists or orthodontists? ;-)

The license is the easy part for GC license and if necessary, the developer license from CCB for Oregon CCB rules... Got to double check. Then of course, Washington state side. I got the business license part down. I'm just located in an area where licensing with both states are required. As for the architectural licensing stuff, that's independent matters. I would probably have my CPBD certification along the lines (helps with obtaining E&O insurance for design along with the regular stuff for contractor license) but that's an independent matter altogether. However, I have to... CYA as necessary. The CCB license is the easy stuff. I probably would need to make or build up connections with dentists or orthodontists but I agree finding investors would be something of a work on the to do list but I don't think it is entirely hard to find but it would definitely be building those connections is something I have to work on.

I plan to primarily focus on construction services for projects that we design versus stuff we aren't the DPs for. (Not saying we wouldn't have consultants like engineers, obviously).

"incite vs insight. there is an excellent pun in that malapropism :)" - Thanks for the correction. I agree but yes, I meant insight.

FYI, there is no such thing as a "developer's license" in either Oregon or Washington. Both require a contractor's license for "land development", but only as actual construction work (moving dirt, building improvements, etc.). None of that applies to putting together a real estate project as "developer" unless you are doing the construction part yourself. You might need a separate real estate license if you intend to buy or sell property on your own without an agent, but otherwise no.

Technically, speaking, yes and no. The semantics is relating to which license tier you get from CCB and its limitations. There are multiple licenses or endorsements from CCB. One is developer (RD or CD endorsement) and there are limitations. I just was kind of simplying it for it is not the same as RGC or CGC Level 1 or 2.

This is what I am referring to: 

https://www.oregon.gov/ccb/Doc...

and the associated ORS 701 and OAR.

If you are under the RD or CD endorsement, there are limits but that is something that is different than RGC. One thing like on-site supervision during construction may require me to possess the RGC or CGC (L1 or L2) endorsement. This is what CCB basically told me. They would expect that I hold an RGC or CGC level. I am unclear if I have to have both an RGC/CGC endorsement and a developer (RD and/or CD) endorsement. That is something I have to check with them. In Washington, it is a little different, from what I recall.

I think you understand that I mean by "developer license" that I meant a CCB license with the RD and/or CD endorsement as compared to RGC, CGC (level 1 or 2), RSC, RLC, CSC, and possibly etc. Then there is the potential LBPR stuff when work may involve buildings built before a certain date. Of course, these are small stuff... bureaucratic crud to deal with. Architect providing construction observation / construction administration is exempt but if I do that, they could interpret that as under construction management and require such license. Given the inherent involvement of multiple trades, they suggested that the license endorsement should be a general contractor (RGC or CGC). Just getting say, an RSC endorsement would likely not be sufficient. It could lead to issues of exceeding the scope of endorsement limits. Just informing from what I had received on my conversation with CCB in the recent past. (within last 18 months). I agree with you about the real estate license stuff. Totally separate matter with another state agency.

Looking at the statutes, it looks like I only need RD/CD endorsement(s) or RGC/CGC (level 1 or 2) endorsement(s) but don't need both developer or general contractor endorsement but if I provide construction administration (as that may be interpreted as falling under construction management) [unless licensed as an Architect or Engineer], I may need either RGC or CGC endorsement and would also be able to serve in a developer role. Construction Administration/Observation services by a person not licensed as an architect/engineer is a very thin grey area left to interpretation. So CCB staff suggested I get an RGC endorsement level license if I provide such to avoid potential issues.

APOLOGIES for the string of multiple posts. I think it is important to cover that now and then move on to other inquiries or matters of this thread. 

Starting with your last question first, I was a design principal at a global mixed-use firm (a couple of them, actually) for quite awhile. But earlier in my career, I had spent a little over seven years as a super-high-end custom home architect, doing exactly the sort of big-dollar wish-fulfillment projects I was describing as "stunts." I always loved doing houses, and after a couple of decades doing giant mixed-use tower projects all over the world, going back to houses was a huge relief. It's much more fun and satisfying for me. On the other hand, without the experience working at scale on the big stuff, this current thing I'm doing would not really have worked. Our company has very aggressive growth and performance goals, which we generally meet. That's not possible without some highly systematic approaches to doing our work, things which the big corporate firms excel at. I've built a team and a system here which can deliver 8 to 9 permitted projects per month with only 12 people, and is set up to scale up and grow at a minimum of 30% year on year for the next decade. That's a critical part of what makes the whole company work as an integrated business.

The whole thing started a few months after I had left my prior position as USA PNW regional practice director for a very, very large firm. I wanted to get into integrated business models much more actively, so had created my own design-development business. I was putting together project deals for a couple of smaller condo conversions and a 39-unit apartment building in the Seattle metro area. I got a call from a home builder on the east side, asking if I would be interested in talking to them about how they might go about bringing architecture in-house as a core business unit (the "third leg of the stool", with the others being real estate and construction). They were really struggling to grow just using consultant architects for an essential, critical path function (design, documentation, permitting). We talked quite a bit about the advantages and challenges associated with having architecture in-house. Specifically, that if you try to do architecture within the company the same way it was being done with consultants, it wouldn't solve any problems at all. It would just make them internal problems rather than external ones. I talked a bit about my own experience, past and present, doing real estate development and architecture together. A few weeks later, they invited me to partner up and create a complete architecture division within the company. That was a little over two years ago.

At first, the "team" was just me, beginning with a deep-dive forensic analysis of what was actually happening in their design-docs-permit pipeline, then putting together a comprehensive strategic plan to create an architecture business division to solve all those problems. By the end of 2021, I had hired up to a team of four, and the permit approval log-jam had been completely unblocked by March 2022. By April 2022, we had built the production system and hired staff to start designing and delivering our own work. By Q2 this year, we were staffed up and running on all cylinders to deliver 100% of our home project designs, documents, and permits in-house with no need for outside consultants anymore.

The parent business, as I mentioned above, was already functioning as a builder-developer for nearly a decade when we did this. We typically self-finance land purchase and bank-finance construction. In the early days, the land was financed too, using a revolving builders' line of credit. We have a good system for developing acquisition leads and doing rapid feasibility analysis on them (architecture is key part of this). Our typical feasibility periods under contract are two weeks or less. Once we commit to an acquisition, the project is then "owned" by architecture until permit approval, at which point it is handed off to construction. In between, we have additional finance, marketing, sales, and other operations in play. We typically pre-sell about 50% of homes.

Since there was already a very robust business system in place for doing real estate acquisitions and finance as well as construction.The missing piece was a similarly robust system for doing architecture, which is what I have since created. The big focus for the next couple of years now is to take those robust systems and fully integrate them. At which point, our longer term strategic goal of being the biggest, best luxury home builder in the US west region will be achievable.

"We talked quite a bit about the advantages and challenges associated with having architecture in-house. Specifically, that if you try to do architecture within the company the same way it was being done with consultants, it wouldn't solve any problems at all. It would just make them internal problems rather than external ones. I talked a bit about my own experience, past and present, doing real estate development and architecture together." 

Can you describe the differences between how things are different from how it is done with consultants? What issues you addressed in your critical path optimization process? I'm curious to learn how this works different from a conventional model.

Consultants are highly constrained by the fact that they are working in a one-off contract basis. Managing the contract, delivery, fees, liability, and a host of other associated issues starts demanding some fairly perverse incentives and focus away from core critical path value. Being under the same roof with real estate, finance, construction, procurement, marketing, sales, etc. completely changes the working dynamic. We are partners in the process from very early in the process, with an opportunity to be part of creating the program, budget, etc. We also have full access to constructability and cost parameters in ways consultants will never really get. We don't worry about CYA stuff to manage liability under our contract because there are no contracts. We're obviously not going to sue ourselves, so where there are issues, the focus is on quick resolution rather than blame games. We don't have to manage fees vs effort at all. Our focus is on meeting timelines and producing critical path deliverables to keep the pipeline going. We never worry about where our next project is coming from and spend zero energy on any kind of marketing or business development. We don't keep time cards and don't care who is spending time doing what so long as stuff is getting done when it needs to. So there is a huge layer of managerial and contractual bullsh*t most consultants spend a lot of energy worrying about, which we don't bother with at all.

On the other hand, we do have real and immediate accountability to our real estate and construction partners on what we are doing. If we design something which has constructability problems or blows up a budget, the whole company's business flow is jeopardized. We can't just design whatever, however we think it should be done, and try to impose that on the process through a contractual role. As soon as we have an approved permit for a project, construction owns it. We don't do anything remotely resembling "construction administration" because that's the construction group's job, not ours. That means we have to give up a fair amount of control as designers. But in return, we get a seat at the table and a voice in the critical decision making which consultants almost never get. The trade-off is more than worth it.

None of this means we don't have any power to affect design outsomes. We very much do. We are responsible for design quality, in many ways with a lot more freedom than consultants typically have. But that design freedom is bounded by the need to always act in partnership with full buy-in from our business partners in the other divisions of the company. If we want to propose an innovative new design strategy, we can't just say that's the design. We have to work with them from a very early stage to get everyone on board to move forward with that.

Stripping away all of the extraneous crap of consultant practice allows us to rigorously focus on our core critical-path function and value-add as architects in the construction industry work flow. As I've mentioned elsewhere, this really comes down to only three things: compelling designs, great documents, and delivering permits. Regardless of their business or contract structure, architects who excel at these three things will always be hugely in demand for our services and command significant compensation premiums on fees or whatever.

Producing great designs is the essence of creating our product: great buildings. A world-class construction operation producing mediocre designs is only ever going to wind up with a mediocre product. Our clients all know this, but it's a difficult thing for them to manage in a predictable way. The design process is a scary, unpredictable unknown that can't easily be quantified in a spreadsheet, yet the success of the entire product is completely dependent on it happening successfully. Many consultant architects struggle with this, as our reputation in the industry clearly indicates. Clients have a lot of frustrations with how we typically do design, and some of them push very hard to try and squeeze it into a manageable box they can control. Only if you can demonstrate an ability to do it really well, really consistently can you get the trust and traction to do it with freedom to make it great. Since we are part of the same organization, we have the ability to gain the understanding and engage the decision process in ways to make design much more effective and successful. We have to stay inside the lines and build a lot of consensus and trust, but doing that gains us a lot more design freedom than we would have as hired guns.

The results have proved the model is successful. The homes we have designed and delivered internally have performed at a much higher level than anything every produced using a consultant process. We get them done a lot faster, with a lot more alignment to company goals, and our customers love them. Even in a very challenging market, our home designs command price premiums and sell very quickly at the same time our competitors are struggling with inventory and making price concessions. Our design quality is better, and people will pay more for it. In return, that earns us the trust in the organization to push for better design to keep that leadership growing and going.

On a much more prosaic level, our core pipeline responsibility is to produce permits quickly to meet construction start pipeline requirements. This is an area where a large majority of architects screw up and have earned a lot of distrust from our clients. Prior to bringing architecture in-house, our architect consultants were taking an average of 11.5 months to get projects through permit reviews, with an average of 2.8 rounds of review corrections on each permit. There was huge pressure on them to get their permit applications submitted to get this brutal process going and the clock ticking. Their response when we asked why it couldn't go faster was always some sort of demurral about city reviews being on bureaucratic time and it all being out of their control. That was a bullsh*t excuse. The reality is that long permit review times are much a function of poor quality inputs than anything going on with permit reviews themselves. Submittals that are wrong, incomplete, poorly coordinated, contradictory, etc. are what make reviews take a long time. If you submit very high-quality, complete, consistent, comprehensive information in your permit application, they will get approved quickly.

So we did two things: we created a system for making permit application documentation which makes doing it correctly the first time much easier, by use of templates, pre-vetted content, checklists, etc. Then we perform rigorous QA reviews ourselves before anything ever gets submitted. Once the submittal is in, we have dedicated permit managers on staff who are responsible for getting their projects approved and act as in-house permit expeditors. The result is that our current average permit review time is just under four months, slightly over a third the consultant performance. Since we also do design in a third or less the time the consultants take, our delivery process for producing permits for construction is vastly more efficient and effective. We can go from a new property to a construction start in a fraction of the time our competitors can, with no sacrifice on quality or cost. Just because we focus on essentials and have implemented very good systems for doing it.

how do you balance what's needed for permit vs what's needed to communicate design to the construction team?

it's easy to get a permit, but your goal is to do better than that

Which leads to the third critical-path component of the architect's value-add: Great documents. We need very high-quality sets of documents to get our projects through permit review quickly. We also need them for our construction teams to build quickly and effectively. Because we are not creating drawings as part of a bid or contract process, we can tailor them to be exactly what we need them to be for each step. Permit sets are created specifically to get permits quickly. Construction sets are created specifically to help our construction people know what they should be doing and how to price it out. We include a lot of things in our drawings which most architects would get heartburn over because of contractual liability, and leave a ton of things out because they just aren't necessary. If there's a question during cost estimating or construction, they just walk down the hall, ask us, and we figure it out directly. In practice, that doesn't happen very often because we are tailoring our designs and documents specifically for them and how they work. That lets them go much faster without sacrificing quality or cost.

Our overall approach with this is to use great systems and tools to empower great people to break the "Iron Triangle" of "Quality, cost, speed ... pick two". We pick all three, and are able to deliver them consistently. Anything which doesn't serve that goal is irrelevant and we discard it. That's much easier because we are all working together as partners under the same roof in the same business organization. I probably sound a little preachy at this point, but it really works and we have been able to accomplish some fairly amazing things doing it in only two years. That's just the beginning. It's more than that. It's the future of our entire industry.

One way not being consultants but being in-house allows us to address many of these issues so effectively is that our financial constraints are associated with overall pipeline performance, not a contractual fee. Consultant architects don't usually have the resources generally or under an specific project fee to build out powerful production systems and tools before they do any billable work. We invested a half-million dollars and four months building our design and documentation system before we ever tried using it on a real project. And we don't nickel-and-dime time spent on QA reviews because we don't care about billable hours or fees. We care about overall performance: the time it takes us to bring a home to market from a new land acquisition. That's what really matters in the real estate world. An extra week of time spent by a few people to really check and fix a permit submittal set to be right will save us months of review time. Easy trade for us to make because our business model encourages rather than inhibits it. We don't worry how we're going to "get paid" for that effort. It's built in. We don't staff up or down in response to project work. We hire strategically to build capacity before we need it, so we can then grow revenue. That's how real businesses work. When we ramp up, the people are already there. And that also means we don't have to constantly force people to work overtime to fill a staffing gap. And that also means we don't just lay people off indiscriminately when markets or the work pipeline fluctuate. Which then makes it vastly easier for us to predict and plan for what we will need to meet our future business goals.

Proto: "how do you balance what's needed for permit vs what's needed to communicate design to the construction team?" 

Our documentation standards and templates are specifically set up to produce drawings sets specifically for their particular purpose with minimal effort. So our permit sets are optimized for getting permits, not being built, and don't include ANYTHING that isn't necessary for getting the permit approved. A separate set of templates is the basis for the construction set, much of which is created through automated application of standard details. We use a highly customized implementation of Revit to do most of this documentation work from a single-source-of-truth model. Our templates are standardized and comprehensive, with nearly everything needed to create a good set of drawings already pre-configured.

Similar to design-build (in the respect that when the design and construction is under the same roof, you don't have to document and communicate as you would when they are separate organizations. Of course, when there is a sub contractor on something, necessary communications in plans would be needed. When things are in-house, you can include things that are traditionally shop drawing level right from get go so the builder doesn't have to go back and forth with shop drawing submission and approval. You integrated things further than design-build. Speaking loosely without claiming they are the same things.

You said it more elegantly.

Having said that, our "construction sets" would probably look ridiculously light and also weirdly non-standard to most consultant architects. The reason is because our construction teams know what they are doing and there is a lot of stuff we don't have to tell them. We don't have to worry about being sued because it's not there. We just know they'll do it to standard. The weirdness comes from ways in which our drawings use some fairly unconventional graphic standards for communicating information. Our window tags on plans, for instance, show a ton of stuff which is there specifically for convenience to the framers, and also link to specialized window schedules set up specifically for cost estimating by our procurement department.

You don't have to communicate to them like they are idiot laborers. Someone competent reads the plans will communicate to the laborers whats needed to be done. You know they know what they are doing and readily available to communicate or clarify without endless cycles of RFCs and change-order drawings to fuss through.

Am I following this, correctly? Sure, active communication but having people you know that knows what he/she is doing and can get it done without all the hand holding processes.

It may take me a bit to figure out all of it ad process the information. A lot to think about, though. So, thank you for sharing this info gwharton. A lot of background material to read up on as well to shore up my understanding. If there are good reading materials that helped you in figuring out these processes, that would be great. Like how you guys worked on customizing Revit, for example and other stuff you guys did in optimization of the processes. Some of us are dinosaurs in this respect.

The big issue most architects have with Revit implementation is that they buy some licenses for the software and then expect their staff to jump in an use it .... like CAD. Revit is a completely different animal which requires a completely different workflow. And to get all the benefit out of it, you have to invest a significant amount of time and money into setting it up correctly for how you want to use it, BEFORE you actually use it for anything on a real project. You need to create all the document templates, all the views, all the families for the types of assemblies and objects you will use, and all the tables and notation blocks. Again, consultant fees don't really support doing that by themselves. We spent a ton of time and money doing it, and I have a person on staff whose main job is keeping it updated and working.

Ah, yes. Revit's stock families are often don't include all the stuff used in residential. Part of the problem I faced with revit. The lack of profiles and families for those milled parts often used in historic houses. Just to illustrate an example. I agree with you. When you try to do it while working on a project, it causes projects to take sometimes significantly longer than with CAD. Once you got the stuff in, it's much easier and you can really begin to gain the benefits of Revit. Using a different example than yours but agree with what you said about Revit.

Much like in programming, if you have a library of reusable code, you can really speed up your programming than writing from scratch every time. You are speaking to an optimization of workflow by putting this upfront effort before using it in your professional workflow. Too bad they just don't include all this stuff or make it a free download pack. That can then be tweaked and adjusted and then implemented for specifics.

is the business a partnership? was there any difficulty employing architects in-house in a non-professional business?

I think midlander is inquiring gwharton?

The business is an LLC. That's fairly standard in the industry now. You get good limitation of liability like a corporation, easy administration and pass-through taxation like a partnership.

We did struggle with hiring architects for a long time. Most architects look at us, think "builder...meh", and pass by looking for a conventional firm

It takes a special kind of unconventional and integrative thinking to succeed doing what we do. Even experienced professionals have to learn new ways of doing familiar things. And I include myself in that.

Re: permit turnaround. This is what one of the municipalities I work in says it takes, experience says it's 3 times that

Yes. The published timelines from municipalities are usually 100% fictional and should not be taken at face value. But as I said, a significant reason for that is very poor quality submittals by applicants. If you tighten up your submittal game and really get it dialed in to what the municipality needs/wants, you can then start to get close to those published numbers, and sometimes do even better.

We do customs too, though only as a small fraction of our work. We can typically deliver them at least twice as fast as our consultant competitors. But that's predicated on working with the system we have built to get great results quickly within budget.

Doing a good job with your design system and client communication management can really streamline a lot of the problems typically associated with getting decisions made during the custom home design process. You really need to keep expectations clear and aligned on an ongoing basis. Where a lot of architects fail in that is combining over-design with poor communication. That's true at every level, in every type of firm, working on every kind of project and it is a major source of frustration with clients.

Multifamily probably has an

Stupid mobile interface.... Trying to respond to this again... 

For-rent multifamily probably has an easier model for doing design-development than for-sale single-family when it comes down to it. Getting the land is a bit more straightforward, and you need fewer parcels per year to work. When stabilize/sell the product, you can usually time things so apartment building income is taxed as a capital gain rather than ordinary income (as is usually the case with for-sale single-family and condos). And getting financing can also be a bit easier, depending on what sort of project you are doing and what your time frames are.

Keeping the design fresh and quality high is certainly a challenge. We have a multi-layered strategy in place for doing that. Part of our market position is "New Homes in Established Neighborhoods." We are not a plat builder who buys land 100 acres at a time and builds the same five home plans by the thousands for economies of scale. We purchase our properties and build our homes one at a time. "Infill" as it's sometimes referred to. That is a much more difficult way to design and build spec homes efficiently, since every one is located on an essentially unique site, and in our case we want every home's design to share in that uniqueness. We don't ever want to have an obviously-same home design located within a 1/4 mile of another version of itself.

At the same time, designing every home from scratch and trying to be completely different with each one is tremendously inefficient and costly. We want to get efficiencies from repetition and economies of scale, but also want to maintain our brand and market position providing individualized homes. To do that, we balance our portfolio between four basic product type approaches, from a blank-page new-design project on one end, to a 90% pre-designed "prototype" design ready to be stitched into a unique lot. And a spectrum in-between ("modified plan re-use," etc.). We then look at each site in acquisition on a case-by-case basis to determine which delivery path we're going to use. Very special, high-value sites always get a new plan even if we have another one which will fit. We also balance across the whole portfolio so that we are not committing to too many of any one type, or locating prototypes or modified re-uses near each other without special changes to differentiate them.

This also creates a design pipeline so that if a one-off design is very successful, we can start looking for opportunities to re-use it with modifications and improvements. That may ultimately feed into the creation of a new prototype design if it's very-very successful over a few instances of use. For prototypes, we have a core plan design dialed in, and then develop multiple design "expressions" (sort of like "styles" but different). The different expressions allow us to use a highly-similar plan which has been vetted by our production processes and validated by market popularity, with totally different visual appearance, to the point where only trained experts can really tell that the plans are the same between two different expressions of the same prototype plan.

This approach also allows us to balance out what our project architects are working on. First, so we are not overloading them with work and conflicting delivery timelines. Second, so that they have a mix of project types on their plate to keep things engaging and interesting. We specifically try to avoid having anyone on the team be doing new-plan projects or re-use/prototypes exclusively. Sometimes they want to dive into creating a fully-new design. Sometimes they want to crank some stuff out. And even with the prototype/re-use work, there's still customization and modification necessary to make them work.

In between, we have a set of design and planning guidelines to help our architects stay in-bounds while developing which kind of project they're working on. It's a little bit like a program guide and kit of parts for doing "our thing" in a way that aligns with company expectations, but it's not prescriptive. It's more like a kick-start for the process and explicit statement of shared understanding. Then we have a very specific process for doing design quickly, effectively, and to a high quality standard which is loosely based on lean design principles and something I developed over decades of leading major project design teams all around the world. The goal is to get decisions made will full stakeholder alignment quickly without pushing into overdesign and risking substantial re-work. At the end of a project design process, it goes to our internal review committee for final Design Approval before being cleared to go into technical design and document production. That dramatically reduces re-work and speeds us up enormously. For a new-plan project, we can get from a blank piece of paper to an approved design ready to go into technical documentation in about a week. For a Prototype, it's one day. It's not always that fast, and our consultants are considerably slower than we are, but we have performed at that level on many projects.

As this system develops and continues to be integrated with the rest of the company, one of our longer term strategic goals is to create a viable hybrid business model which works in the space between production building and full custom. I like to think of that target is the capacity to do Mass Customization. Ultimately, we want our system to be so good, so effective, and so fast that we can do all new-plan design for anybody who wants a customized design, and do it as fast as if it was an off-the-shelf product. That's very ambitious, and we're a long way from making it happen, but the pieces are all there now.

RE: Jaymarc, they are a good company and I know their President personally from college days. The scale of their operation is considerably smaller than ours and works very differently.

We are intentionally agnostic about tools for design, with the single exception that there is a ban on using Revit until AFTER design approval is reached. Using Revit for design pretty much forces the designer to overdesign and get way too far out over their skis in the process. We want fast and loose in design, not precision and detail.

I agree. Revit like CAD are technical drawing tools not meant or intended for rapid ideation. Rapid design ideation is better to use tools like paper and pencil/pen. Quick sketching. Some intermediate designing can be looked at with other tools like SketchUp for example. gwharton, your approach makes sense to me and I prefer to sketch and ideate outside of tools like CAD or BIM (Revit) in those stages and later in the design process as we move towards technical drawings to transition over to those tools. For me, I may use the pen/pencil and paper and sometimes I may use certain digital tools that is similar to pen/paper. I have one of those reMarkable 2 tablet things that are convenient. My phone is in my opinion too small ... too constrained but then any phone would be. For drawing, I need a little more area, in my personal comfort but is at least comparable to a digital Moleskine sketchbook and fine for field documentation.

thanks, gwharton. your revit response was to be expected. i was pleasantly surprised by your approach to being intentionally agnostic regarding design tools. much appreciated.

I'm happy to discuss. We don't really do remote work or part time stuff, but I don't mind answering questions or helping people learn the ropes.